Building energy management system with ad hoc dashboard

ABSTRACT

A building energy management includes building equipment, one or more data platform services, a timeseries database, and an energy management application. The building equipment operate to monitor and control a variable and provide raw data samples of a data point associated with the variable. The timeseries database stores a plurality of timeseries associated with the data point. The plurality of timeseries include a timeseries of the raw data samples and the one or more optimized data timeseries generated by the data platform services based on the raw data timeseries. The energy management application generates an ad hoc dashboard including a widget and associates the widget with the data point. The widget displays a graphical visualization of the plurality of timeseries associated with the data point and includes interactive user interface options for switching between the plurality of timeseries associated with the data point.

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/408,404 filed Jan. 17, 2017 which claims the benefit of and priorityto U.S. Provisional Patent Application No. 62/286,273 filed Jan. 22,2016. U.S. patent application Ser. No. 15/408,404 filed Jan. 17, 2017 isalso a continuation-in-part of both U.S. patent application Ser. No.15/182,579 filed Jun. 14, 2016 and U.S. patent application Ser. No.15/182,580 filed Jun. 14, 2016. The entire disclosure of each of thesepatent applications is incorporated by reference herein.

BACKGROUND

The present disclosure relates generally to the field of buildingmanagement systems. A building management system (BMS) is, in general, asystem of devices configured to control, monitor, and manage equipmentin or around a building or building area. A BMS can include, forexample, a HVAC system, a security system, a lighting system, a firealerting system, any other system that is capable of managing buildingfunctions or devices, or any combination thereof.

A BMS can collect data from sensors and other types of buildingequipment. Data can be collected over time and combined into streams oftimeseries data. Each sample of the timeseries data can include atimestamp and a data value. Some BMSs store raw timeseries data in arelational database without significant organization or processing atthe time of data collection. Applications that consume the timeseriesdata are typically responsible for retrieving the raw timeseries datafrom the database and generating views of the timeseries data that canbe presented via a chart, graph, or other user interface. Theseprocessing steps are typically performed in response to a request forthe timeseries data, which can significantly delay data presentation atquery time.

SUMMARY

One implementation of the present disclosure is a building energymanagement system. The system includes building equipment, a datacollector, one or more data platform services, a timeseries database,and an energy management application. The building equipment areoperable to monitor and control a variable in the building energymanagement system and configured to provide raw data samples of a datapoint associated with the variable. The data collector is configured tocollect the raw data samples from the building equipment and generate araw data timeseries including a plurality of the raw data samples. Thedata platform services are configured to generate one or more optimizeddata timeseries from the raw data timeseries. The timeseries database isconfigured to store a plurality of timeseries associated with the datapoint. The plurality of timeseries include the raw data timeseries andthe one or more optimized data timeseries. The energy managementapplication is configured to generate an ad hoc dashboard including awidget and to associate the widget with the data point. The widget isconfigured to display a graphical visualization of the plurality oftimeseries associated with the data point and includes interactive userinterface options for switching between the plurality of timeseriesassociated with the data point.

In some embodiments, the data platform services include a sampleaggregator configured to automatically generate a data rollup timeseriesincluding a plurality of aggregated data samples by aggregating the rawdata samples as the raw data samples are collected from the buildingequipment and store the data rollup timeseries in the timeseriesdatabase as one of the optimized data timeseries.

In some embodiments, the data platform services include a virtual pointcalculator configured to create a virtual data point representing anon-measured variable, calculate data values for a plurality of samplesof the virtual data point as a function of the raw data samples,generate a virtual point timeseries including the plurality of samplesof the virtual data point, and store the virtual point timeseries in thetimeseries database as one of the optimized data timeseries.

In some embodiments, the data platform services include an analyticsservice configured to perform one or more analytics using the raw datatimeseries, generate a results timeseries including a plurality ofresult samples indicating results of the analytics, and store theresults timeseries in the timeseries database as one of the optimizeddata timeseries.

In some embodiments, the ad hoc dashboard includes a widget creationinterface including a plurality of selectable widget types. Each of thewidget types may correspond to a different type of widget the ad hocdashboard is configured to create. The widget types may include at leastone of a charting widget, a data visualization widget, a display widget,a time or date widget, and a weather information widget.

In some embodiments, the widget is a charting widget configured todisplay a chart of the plurality of timeseries associated with the datapoint. The chart may include at least one of a line chart, an areachart, a column chart, a bar chart, a stacked chart, and a pie chart.

In some embodiments, the timeseries database is configured to store aplurality of timeseries associated with a plurality of different datapoints. In some embodiments, the ad hoc dashboard is configured toassociate the widget with each of the plurality of timeseries associatedwith the plurality of different data points. The widget may beconfigured to display a graphical visualization of each of the pluralityof timeseries associated with the widget.

In some embodiments, the widget is configured to determine a unit ofmeasure for each of the plurality of timeseries associated with thewidget and generate a line chart including a plurality of lines. Each ofthe plurality of lines may correspond to one or the plurality oftimeseries associated with the widget. The widget may assign a commoncolor to each of the plurality of lines corresponding to timeseries withthe same unit of measure and may assign different colors to each of theplurality of lines corresponding to timeseries with different units ofmeasure.

In some embodiments, the widget is configured to generate a heat mapincluding a plurality of cells. Each of the cells may correspond to adifferent sample of the data point associated with the widget. Thewidget may be configured to identify a numerical data value for each ofthe samples corresponding to the cells of the heat map and may assign acolor to each cell of the heat map based on the numerical data value ofthe corresponding sample.

In some embodiments, the ad hoc dashboard is configured to display apoints list including a plurality of points detected in the buildingenergy management system, receive a user input dragging and dropping oneor more of the points from the points list onto the widget, andassociate the one or more points with the widget in response to the userinput dragging and dropping one or more of the points from the pointslist onto the widget.

Another implementation of the present disclosure is a method forgenerating an ad hoc dashboard in a building energy management system.The method includes operating building equipment to monitor and controla variable in the building energy management system, collecting raw datasamples of a data point associated with the variable from the buildingequipment, generating a raw data timeseries including a plurality of theraw data samples, generating one or more optimized data timeseries fromthe raw data timeseries, and storing a plurality of timeseriesassociated with the data point in a timeseries database. The pluralityof timeseries include the raw data timeseries and the one or moreoptimized data timeseries. The method further includes generating an adhoc dashboard including a widget associated with the data point. Thewidget is configured to display a graphical visualization of theplurality of timeseries associated with the data point and includesinteractive user interface options for switching between the pluralityof timeseries associated with the data point.

In some embodiments, generating the one or more optimized datatimeseries includes automatically generating a data rollup timeseriesincluding a plurality of aggregated data samples. The data rolluptimeseries can be generated by aggregating the raw data samples as theraw data samples are collected from the building equipment. The methodmay include storing the data rollup timeseries in the timeseriesdatabase as one of the optimized data timeseries.

In some embodiments, generating the one or more optimized datatimeseries includes creating a virtual data point representing anon-measured variable, calculating data values for a plurality ofsamples of the virtual data point as a function of the raw data samples,generating a virtual point timeseries including the plurality of samplesof the virtual data point, and storing the virtual point timeseries inthe timeseries database as one of the optimized data timeseries.

In some embodiments, generating the one or more optimized datatimeseries includes performing one or more analytics using the raw datatimeseries, generating a results timeseries including a plurality ofresult samples indicating results of the analytics, and storing theresults timeseries in the timeseries database as one of the optimizeddata timeseries.

In some embodiments, the method includes presenting, via the ad hocdashboard, a widget creation interface including a plurality ofselectable widget types. Each of the widget types may correspond to adifferent type of widget the ad hoc dashboard is configured to create.The widget types may include at least one of a charting widget, a datavisualization widget, a display widget, a time or date widget, and aweather information widget.

In some embodiments, the method includes displaying, in the widget, achart of the plurality of timeseries associated with the data point. Thechart may include at least one of a line chart, an area chart, a columnchart, a bar chart, a stacked chart, and a pie chart.

In some embodiments, the method includes storing a plurality oftimeseries associated with a plurality of different data points in thetimeseries database, associating the widget with each of the pluralityof timeseries associated with the plurality of different data points,and displaying, in the widget, a graphical visualization of each of theplurality of timeseries associated with the widget.

In some embodiments, the method includes determining a unit of measurefor each of the plurality of timeseries associated with the widget andgenerating a line chart including a plurality of lines. Each of theplurality of lines may correspond to one or the plurality of timeseriesassociated with the widget. The method may include assigning a commoncolor to each of the plurality of lines corresponding to timeseries withthe same unit of measure and assigning different colors to each of theplurality of lines corresponding to timeseries with different units ofmeasure.

In some embodiments, the method includes generating a heat map includinga plurality of cells. Each of the cells may correspond to a differentsample of the data point associated with the widget. The method mayinclude identifying a numerical data value for each of the samplescorresponding to the cells of the heat map and assigning a color to eachcell of the heat map based on the numerical data value of thecorresponding sample.

In some embodiments, the method includes displaying a points listincluding a plurality of points detected in the building energymanagement system, receiving a user input dragging and dropping one ormore of the points from the points list onto the widget, and associatingthe one or more points with the widget in response to the user inputdragging and dropping one or more of the points from the points listonto the widget.

Those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, inventive features, and advantages of the devices and/orprocesses described herein, as defined solely by the claims, will becomeapparent in the detailed description set forth herein and taken inconjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a drawing of a building equipped with a building managementsystem (BMS) and a HVAC system, according to some embodiments.

FIG. 2 is a schematic of a waterside system which can be used as part ofthe HVAC system of FIG. 1, according to some embodiments.

FIG. 3 is a block diagram of an airside system which can be used as partof the HVAC system of FIG. 1, according to some embodiments.

FIG. 4 is a block diagram of a BMS which can be used in the building ofFIG. 1, according to some embodiments.

FIG. 5 is a block diagram of another BMS which can be used in thebuilding of FIG. 1. The BMS is shown to include a data collector, dataplatform services, applications, and a dashboard layout generator,according to some embodiments.

FIG. 6 is a block diagram of a timeseries service and an analyticsservice which can be implemented as some of the data platform servicesshown in FIG. 5, according to some embodiments.

FIG. 7A is a block diagram illustrating an aggregation technique whichcan be used by the sample aggregator shown in FIG. 6 to aggregate rawdata samples, according to some embodiments.

FIG. 7B is a data table which can be used to store raw data timeseriesand a variety of optimized data timeseries which can be generated by thetimeseries service of FIG. 6, according to some embodiments.

FIG. 8 is a drawing of several timeseries illustrating thesynchronization of data samples which can be performed by the dataaggregator shown in FIG. 6, according to some embodiments.

FIG. 9A is a flow diagram illustrating the creation and storage of afault detection timeseries which can be performed by the job managershown in FIG. 6, according to some embodiments.

FIG. 9B is a data table which can be used to store the raw datatimeseries and the fault detection timeseries, according to someembodiments.

FIG. 9C is a flow diagram illustrating how various timeseries can begenerated, stored, and used by the data platform services of FIG. 5,according to some embodiments.

FIG. 10A is an entity graph illustrating relationships between anorganization, a space, a system, a point, and a timeseries, which can beused by the data collector of FIG. 5, according to some embodiments.

FIG. 10B is an example of an entity graph for a particular buildingmanagement system according to some embodiments.

FIG. 11 is an object relationship diagram illustrating relationshipsbetween an entity template, a point, a timeseries, and a data sample,which can be used by the data collector of FIG. 5 and the timeseriesservice of FIG. 6, according to some embodiments.

FIG. 12 is a flow diagram illustrating the operation of the dashboardlayout generator of FIG. 5, according to some embodiments.

FIG. 13 is a grid illustrating dashboard layout description which can begenerated by the dashboard layout generator of FIG. 5, according to someembodiments.

FIG. 14 is an example of object code describing a dashboard layout whichcan be generated by the dashboard layout generator of FIG. 5, accordingto some embodiments.

FIG. 15 is a user interface illustrating a dashboard layout which can begenerated from the dashboard layout description of FIG. 14, according tosome embodiments.

FIG. 16 is another example of object code describing another dashboardlayout which can be generated by the dashboard layout generator of FIG.5, according to some embodiments.

FIG. 17 is a user interface illustrating a dashboard layout which can begenerated from the dashboard layout description of FIG. 16, according tosome embodiments.

FIG. 18 is a login interface which may be generated by the BMS of FIG.5, according to some embodiments.

FIGS. 19-34 are drawings of an overview dashboard which may be generatedby the BMS of FIG. 5, according to some embodiments.

FIG. 35 is a flowchart of a process for configuring an energy managementapplication, according to some embodiments.

FIGS. 36-39 are drawings of an interface for configuring spaces, whichmay be generated by the BMS of FIG. 5, according to some embodiments.

FIGS. 40-45 are drawings of an interface for configuring data sources,which may be generated by the BMS of FIG. 5, according to someembodiments.

FIG. 46-49 are drawings of an interface for configuring meters, whichmay be generated by the BMS of FIG. 5, according to some embodiments.

FIGS. 50-51 are additional drawings of the overview dashboard shown inFIGS. 19-34, according to some embodiments.

FIG. 52 is a block diagram illustrating the analytics service of FIG. 6in greater detail showing a weather normalization module, an energybenchmarking module, a baseline comparison module, a night/daycomparison module, and a weekend/weekday comparison module, according tosome embodiments.

FIG. 53 is a flowchart of a process which may be performed by theweather normalization module of FIG. 52, according to some embodiments.

FIG. 54 is a graph illustrating a regression model which may begenerated by the weather normalization module of FIG. 52, according tosome embodiments.

FIG. 55 is a chart of energy use intensity values, which may begenerated by the energy benchmarking module of FIG. 52, according tosome embodiments.

FIG. 56 is a chart of building energy consumption relative to abaseline, which may be generated by the baseline comparison module ofFIG. 52, according to some embodiments.

FIG. 57 is a chart of building energy consumption, which may begenerated by the night/day comparison module of FIG. 52, highlighting aday with a high nighttime-to-daytime energy consumption ratio, accordingto some embodiments.

FIG. 58 is a chart of building energy consumption, which may begenerated by the weekend/weekday comparison module of FIG. 52,highlighting a weekend with a high weekend-to-weekday energy consumptionratio, according to some embodiments.

FIG. 59 is an ad hoc interface which may be generated by the BMS of FIG.5, according to some embodiments.

FIGS. 60-61 are interfaces for creating widgets in the ad hoc interfaceof FIG. 59, according to some embodiments.

FIGS. 62-63 are interfaces for configuring widgets in the ad hocinterface of FIG. 59, according to some embodiments.

FIGS. 64-66 are interfaces for aggregating and displaying timeseriesdata in the ad hoc interface of FIG. 59, according to some embodiments.

FIGS. 67-69 are interfaces for creating and configuring heat map widgetsin the ad hoc interface of FIG. 59, according to some embodiments.

FIGS. 70-71 are interfaces for creating and configuring text box widgetsin the ad hoc interface of FIG. 59, according to some embodiments.

FIGS. 72-73 are interfaces for creating and configuring image widgets inthe ad hoc interface of FIG. 59, according to some embodiments.

FIGS. 74-75 are interfaces for creating and configuring date widgets inthe ad hoc interface of FIG. 59, according to some embodiments.

FIGS. 76-78 are interfaces for creating and configuring clock widgets inthe ad hoc interface of FIG. 59, according to some embodiments.

FIGS. 79-81 are interfaces for creating and configuring weather widgetsin the ad hoc interface of FIG. 59, according to some embodiments.

FIGS. 82-83 are interfaces for sharing the ad hoc interface of FIG. 59with other users or groups, according to some embodiments.

FIGS. 84-85 are interfaces for creating and configuring stacked chartwidgets in the ad hoc interface of FIG. 59, according to someembodiments.

FIGS. 86-87 are interfaces for creating and configuring pie chartwidgets in the ad hoc interface of FIG. 59, according to someembodiments.

FIG. 88 is a point configuration interface with options to define astuck point definition, according to some embodiments.

FIG. 89 is a pending fault interface which can be used to displaydetected faults to a user, according to some embodiments.

DETAILED DESCRIPTION Overview

Referring generally to the FIGURES, a building management system (BMS)with virtual data points, optimized data integration, and aframework-agnostic dashboard layout is shown, according to variousembodiments. The BMS is configured to collect data samples from buildingequipment (e.g., sensors, controllable devices, building subsystems,etc.) and generate raw timeseries data from the data samples. The BMScan process the raw timeseries data using a variety of data platformservices to generate optimized timeseries data (e.g., data rolluptimeseries, virtual point timeseries, fault detection timeseries, etc.).The optimized timeseries data can be provided to various applicationsand/or stored in local or hosted storage. In some embodiments, the BMSincludes three different layers that separate (1) data collection, (2)data storage, retrieval, and analysis, and (3) data visualization. Thisallows the BMS to support a variety of applications that use theoptimized timeseries data and allows new applications to reuse theinfrastructure provided by the data platform services. These and otherfeatures of the BMS are described in greater detail below.

Building Management System and HVAC System

Referring now to FIGS. 1-4, an exemplary building management system(BMS) and HVAC system in which the systems and methods of the presentdisclosure can be implemented are shown, according to an exemplaryembodiment. Referring particularly to FIG. 1, a perspective view of abuilding 10 is shown. Building 10 is served by a BMS. A BMS is, ingeneral, a system of devices configured to control, monitor, and manageequipment in or around a building or building area. A BMS can include,for example, a HVAC system, a security system, a lighting system, a firealerting system, any other system that is capable of managing buildingfunctions or devices, or any combination thereof.

The BMS that serves building 10 includes an HVAC system 100. HVAC system100 can include a plurality of HVAC devices (e.g., heaters, chillers,air handling units, pumps, fans, thermal energy storage, etc.)configured to provide heating, cooling, ventilation, or other servicesfor building 10. For example, HVAC system 100 is shown to include awaterside system 120 and an airside system 130. Waterside system 120 canprovide a heated or chilled fluid to an air handling unit of airsidesystem 130. Airside system 130 can use the heated or chilled fluid toheat or cool an airflow provided to building 10. An exemplary watersidesystem and airside system which can be used in HVAC system 100 aredescribed in greater detail with reference to FIGS. 2-3.

HVAC system 100 is shown to include a chiller 102, a boiler 104, and arooftop air handling unit (AHU) 106. Waterside system 120 can use boiler104 and chiller 102 to heat or cool a working fluid (e.g., water,glycol, etc.) and can circulate the working fluid to AHU 106. In variousembodiments, the HVAC devices of waterside system 120 can be located inor around building 10 (as shown in FIG. 1) or at an offsite locationsuch as a central plant (e.g., a chiller plant, a steam plant, a heatplant, etc.). The working fluid can be heated in boiler 104 or cooled inchiller 102, depending on whether heating or cooling is required inbuilding 10. Boiler 104 can add heat to the circulated fluid, forexample, by burning a combustible material (e.g., natural gas) or usingan electric heating element. Chiller 102 can place the circulated fluidin a heat exchange relationship with another fluid (e.g., a refrigerant)in a heat exchanger (e.g., an evaporator) to absorb heat from thecirculated fluid. The working fluid from chiller 102 and/or boiler 104can be transported to AHU 106 via piping 108.

AHU 106 can place the working fluid in a heat exchange relationship withan airflow passing through AHU 106 (e.g., via one or more stages ofcooling coils and/or heating coils). The airflow can be, for example,outside air, return air from within building 10, or a combination ofboth. AHU 106 can transfer heat between the airflow and the workingfluid to provide heating or cooling for the airflow. For example, AHU106 can include one or more fans or blowers configured to pass theairflow over or through a heat exchanger containing the working fluid.The working fluid can then return to chiller 102 or boiler 104 viapiping 110.

Airside system 130 can deliver the airflow supplied by AHU 106 (i.e.,the supply airflow) to building 10 via air supply ducts 112 and canprovide return air from building 10 to AHU 106 via air return ducts 114.In some embodiments, airside system 130 includes multiple variable airvolume (VAV) units 116. For example, airside system 130 is shown toinclude a separate VAV unit 116 on each floor or zone of building 10.VAV units 116 can include dampers or other flow control elements thatcan be operated to control an amount of the supply airflow provided toindividual zones of building 10. In other embodiments, airside system130 delivers the supply airflow into one or more zones of building 10(e.g., via supply ducts 112) without using intermediate VAV units 116 orother flow control elements. AHU 106 can include various sensors (e.g.,temperature sensors, pressure sensors, etc.) configured to measureattributes of the supply airflow. AHU 106 can receive input from sensorslocated within AHU 106 and/or within the building zone and can adjustthe flow rate, temperature, or other attributes of the supply airflowthrough AHU 106 to achieve setpoint conditions for the building zone.

Referring now to FIG. 2, a block diagram of a waterside system 200 isshown, according to an exemplary embodiment. In various embodiments,waterside system 200 can supplement or replace waterside system 120 inHVAC system 100 or can be implemented separate from HVAC system 100.When implemented in HVAC system 100, waterside system 200 can include asubset of the HVAC devices in HVAC system 100 (e.g., boiler 104, chiller102, pumps, valves, etc.) and can operate to supply a heated or chilledfluid to AHU 106. The HVAC devices of waterside system 200 can belocated within building 10 (e.g., as components of waterside system 120)or at an offsite location such as a central plant.

In FIG. 2, waterside system 200 is shown as a central plant having aplurality of subplants 202-212. Subplants 202-212 are shown to include aheater subplant 202, a heat recovery chiller subplant 204, a chillersubplant 206, a cooling tower subplant 208, a hot thermal energy storage(TES) subplant 210, and a cold thermal energy storage (TES) subplant212. Subplants 202-212 consume resources (e.g., water, natural gas,electricity, etc.) from utilities to serve the thermal energy loads(e.g., hot water, cold water, heating, cooling, etc.) of a building orcampus. For example, heater subplant 202 can be configured to heat waterin a hot water loop 214 that circulates the hot water between heatersubplant 202 and building 10. Chiller subplant 206 can be configured tochill water in a cold water loop 216 that circulates the cold waterbetween chiller subplant 206 building 10. Heat recovery chiller subplant204 can be configured to transfer heat from cold water loop 216 to hotwater loop 214 to provide additional heating for the hot water andadditional cooling for the cold water. Condenser water loop 218 canabsorb heat from the cold water in chiller subplant 206 and reject theabsorbed heat in cooling tower subplant 208 or transfer the absorbedheat to hot water loop 214. Hot TES subplant 210 and cold TES subplant212 can store hot and cold thermal energy, respectively, for subsequentuse.

Hot water loop 214 and cold water loop 216 can deliver the heated and/orchilled water to air handlers located on the rooftop of building 10(e.g., AHU 106) or to individual floors or zones of building 10 (e.g.,VAV units 116). The air handlers push air past heat exchangers (e.g.,heating coils or cooling coils) through which the water flows to provideheating or cooling for the air. The heated or cooled air can bedelivered to individual zones of building 10 to serve the thermal energyloads of building 10. The water then returns to subplants 202-212 toreceive further heating or cooling.

Although subplants 202-212 are shown and described as heating andcooling water for circulation to a building, it is understood that anyother type of working fluid (e.g., glycol, CO2, etc.) can be used inplace of or in addition to water to serve the thermal energy loads. Inother embodiments, subplants 202-212 can provide heating and/or coolingdirectly to the building or campus without requiring an intermediateheat transfer fluid. These and other variations to waterside system 200are within the teachings of the present invention.

Each of subplants 202-212 can include a variety of equipment configuredto facilitate the functions of the subplant. For example, heatersubplant 202 is shown to include a plurality of heating elements 220(e.g., boilers, electric heaters, etc.) configured to add heat to thehot water in hot water loop 214. Heater subplant 202 is also shown toinclude several pumps 222 and 224 configured to circulate the hot waterin hot water loop 214 and to control the flow rate of the hot waterthrough individual heating elements 220. Chiller subplant 206 is shownto include a plurality of chillers 232 configured to remove heat fromthe cold water in cold water loop 216. Chiller subplant 206 is alsoshown to include several pumps 234 and 236 configured to circulate thecold water in cold water loop 216 and to control the flow rate of thecold water through individual chillers 232.

Heat recovery chiller subplant 204 is shown to include a plurality ofheat recovery heat exchangers 226 (e.g., refrigeration circuits)configured to transfer heat from cold water loop 216 to hot water loop214. Heat recovery chiller subplant 204 is also shown to include severalpumps 228 and 230 configured to circulate the hot water and/or coldwater through heat recovery heat exchangers 226 and to control the flowrate of the water through individual heat recovery heat exchangers 226.Cooling tower subplant 208 is shown to include a plurality of coolingtowers 238 configured to remove heat from the condenser water incondenser water loop 218. Cooling tower subplant 208 is also shown toinclude several pumps 240 configured to circulate the condenser water incondenser water loop 218 and to control the flow rate of the condenserwater through individual cooling towers 238.

Hot TES subplant 210 is shown to include a hot TES tank 242 configuredto store the hot water for later use. Hot TES subplant 210 can alsoinclude one or more pumps or valves configured to control the flow rateof the hot water into or out of hot TES tank 242. Cold TES subplant 212is shown to include cold TES tanks 244 configured to store the coldwater for later use. Cold TES subplant 212 can also include one or morepumps or valves configured to control the flow rate of the cold waterinto or out of cold TES tanks 244.

In some embodiments, one or more of the pumps in waterside system 200(e.g., pumps 222, 224, 228, 230, 234, 236, and/or 240) or pipelines inwaterside system 200 include an isolation valve associated therewith.Isolation valves can be integrated with the pumps or positioned upstreamor downstream of the pumps to control the fluid flows in watersidesystem 200. In various embodiments, waterside system 200 can includemore, fewer, or different types of devices and/or subplants based on theparticular configuration of waterside system 200 and the types of loadsserved by waterside system 200.

Referring now to FIG. 3, a block diagram of an airside system 300 isshown, according to an exemplary embodiment. In various embodiments,airside system 300 can supplement or replace airside system 130 in HVACsystem 100 or can be implemented separate from HVAC system 100. Whenimplemented in HVAC system 100, airside system 300 can include a subsetof the HVAC devices in HVAC system 100 (e.g., AHU 106, VAV units 116,ducts 112-114, fans, dampers, etc.) and can be located in or aroundbuilding 10. Airside system 300 can operate to heat or cool an airflowprovided to building 10 using a heated or chilled fluid provided bywaterside system 200.

In FIG. 3, airside system 300 is shown to include an economizer-type airhandling unit (AHU) 302. Economizer-type AHUs vary the amount of outsideair and return air used by the air handling unit for heating or cooling.For example, AHU 302 can receive return air 304 from building zone 306via return air duct 308 and can deliver supply air 310 to building zone306 via supply air duct 312. In some embodiments, AHU 302 is a rooftopunit located on the roof of building 10 (e.g., AHU 106 as shown inFIG. 1) or otherwise positioned to receive both return air 304 andoutside air 314. AHU 302 can be configured to operate exhaust air damper316, mixing damper 318, and outside air damper 320 to control an amountof outside air 314 and return air 304 that combine to form supply air310. Any return air 304 that does not pass through mixing damper 318 canbe exhausted from AHU 302 through exhaust damper 316 as exhaust air 322.

Each of dampers 316-320 can be operated by an actuator. For example,exhaust air damper 316 can be operated by actuator 324, mixing damper318 can be operated by actuator 326, and outside air damper 320 can beoperated by actuator 328. Actuators 324-328 can communicate with an AHUcontroller 330 via a communications link 332. Actuators 324-328 canreceive control signals from AHU controller 330 and can provide feedbacksignals to AHU controller 330. Feedback signals can include, forexample, an indication of a current actuator or damper position, anamount of torque or force exerted by the actuator, diagnosticinformation (e.g., results of diagnostic tests performed by actuators324-328), status information, commissioning information, configurationsettings, calibration data, and/or other types of information or datathat can be collected, stored, or used by actuators 324-328. AHUcontroller 330 can be an economizer controller configured to use one ormore control algorithms (e.g., state-based algorithms, extremum seekingcontrol (ESC) algorithms, proportional-integral (PI) control algorithms,proportional-integral-derivative (PID) control algorithms, modelpredictive control (MPC) algorithms, feedback control algorithms, etc.)to control actuators 324-328.

Still referring to FIG. 3, AHU 302 is shown to include a cooling coil334, a heating coil 336, and a fan 338 positioned within supply air duct312. Fan 338 can be configured to force supply air 310 through coolingcoil 334 and/or heating coil 336 and provide supply air 310 to buildingzone 306. AHU controller 330 can communicate with fan 338 viacommunications link 340 to control a flow rate of supply air 310. Insome embodiments, AHU controller 330 controls an amount of heating orcooling applied to supply air 310 by modulating a speed of fan 338.

Cooling coil 334 can receive a chilled fluid from waterside system 200(e.g., from cold water loop 216) via piping 342 and can return thechilled fluid to waterside system 200 via piping 344. Valve 346 can bepositioned along piping 342 or piping 344 to control a flow rate of thechilled fluid through cooling coil 334. In some embodiments, coolingcoil 334 includes multiple stages of cooling coils that can beindependently activated and deactivated (e.g., by AHU controller 330, byBMS controller 366, etc.) to modulate an amount of cooling applied tosupply air 310.

Heating coil 336 can receive a heated fluid from waterside system 200(e.g., from hot water loop 214) via piping 348 and can return the heatedfluid to waterside system 200 via piping 350. Valve 352 can bepositioned along piping 348 or piping 350 to control a flow rate of theheated fluid through heating coil 336. In some embodiments, heating coil336 includes multiple stages of heating coils that can be independentlyactivated and deactivated (e.g., by AHU controller 330, by BMScontroller 366, etc.) to modulate an amount of heating applied to supplyair 310.

Each of valves 346 and 352 can be controlled by an actuator. Forexample, valve 346 can be controlled by actuator 354 and valve 352 canbe controlled by actuator 356. Actuators 354-356 can communicate withAHU controller 330 via communications links 358-360. Actuators 354-356can receive control signals from AHU controller 330 and can providefeedback signals to controller 330. In some embodiments, AHU controller330 receives a measurement of the supply air temperature from atemperature sensor 362 positioned in supply air duct 312 (e.g.,downstream of cooling coil 334 and/or heating coil 336). AHU controller330 can also receive a measurement of the temperature of building zone306 from a temperature sensor 364 located in building zone 306.

In some embodiments, AHU controller 330 operates valves 346 and 352 viaactuators 354-356 to modulate an amount of heating or cooling providedto supply air 310 (e.g., to achieve a setpoint temperature for supplyair 310 or to maintain the temperature of supply air 310 within asetpoint temperature range). The positions of valves 346 and 352 affectthe amount of heating or cooling provided to supply air 310 by coolingcoil 334 or heating coil 336 and may correlate with the amount of energyconsumed to achieve a desired supply air temperature. AHU controller 330can control the temperature of supply air 310 and/or building zone 306by activating or deactivating coils 334-336, adjusting a speed of fan338, or a combination of both.

Still referring to FIG. 3, airside system 300 is shown to include abuilding management system (BMS) controller 366 and a client device 368.BMS controller 366 can include one or more computer systems (e.g.,servers, supervisory controllers, subsystem controllers, etc.) thatserve as system level controllers, application or data servers, headnodes, or master controllers for airside system 300, waterside system200, HVAC system 100, and/or other controllable systems that servebuilding 10. BMS controller 366 can communicate with multiple downstreambuilding systems or subsystems (e.g., HVAC system 100, a securitysystem, a lighting system, waterside system 200, etc.) via acommunications link 370 according to like or disparate protocols (e.g.,LON, BACnet, etc.). In various embodiments, AHU controller 330 and BMScontroller 366 can be separate (as shown in FIG. 3) or integrated. In anintegrated implementation, AHU controller 330 can be a software moduleconfigured for execution by a processor of BMS controller 366.

In some embodiments, AHU controller 330 receives information from BMScontroller 366 (e.g., commands, setpoints, operating boundaries, etc.)and provides information to BMS controller 366 (e.g., temperaturemeasurements, valve or actuator positions, operating statuses,diagnostics, etc.). For example, AHU controller 330 can provide BMScontroller 366 with temperature measurements from temperature sensors362-364, equipment on/off states, equipment operating capacities, and/orany other information that can be used by BMS controller 366 to monitoror control a variable state or condition within building zone 306.

Client device 368 can include one or more human-machine interfaces orclient interfaces (e.g., graphical user interfaces, reportinginterfaces, text-based computer interfaces, client-facing web services,web servers that provide pages to web clients, etc.) for controlling,viewing, or otherwise interacting with HVAC system 100, its subsystems,and/or devices. Client device 368 can be a computer workstation, aclient terminal, a remote or local interface, or any other type of userinterface device. Client device 368 can be a stationary terminal or amobile device. For example, client device 368 can be a desktop computer,a computer server with a user interface, a laptop computer, a tablet, asmartphone, a PDA, or any other type of mobile or non-mobile device.Client device 368 can communicate with BMS controller 366 and/or AHUcontroller 330 via communications link 372.

Referring now to FIG. 4, a block diagram of a building management system(BMS) 400 is shown, according to an exemplary embodiment. BMS 400 can beimplemented in building 10 to automatically monitor and control variousbuilding functions. BMS 400 is shown to include BMS controller 366 and aplurality of building subsystems 428. Building subsystems 428 are shownto include a building electrical subsystem 434, an informationcommunication technology (ICT) subsystem 436, a security subsystem 438,a HVAC subsystem 440, a lighting subsystem 442, a lift/escalatorssubsystem 432, and a fire safety subsystem 430. In various embodiments,building subsystems 428 can include fewer, additional, or alternativesubsystems. For example, building subsystems 428 can also oralternatively include a refrigeration subsystem, an advertising orsignage subsystem, a cooking subsystem, a vending subsystem, a printeror copy service subsystem, or any other type of building subsystem thatuses controllable equipment and/or sensors to monitor or controlbuilding 10. In some embodiments, building subsystems 428 includewaterside system 200 and/or airside system 300, as described withreference to FIGS. 2-3.

Each of building subsystems 428 can include any number of devices,controllers, and connections for completing its individual functions andcontrol activities. HVAC subsystem 440 can include many of the samecomponents as HVAC system 100, as described with reference to FIGS. 1-3.For example, HVAC subsystem 440 can include a chiller, a boiler, anynumber of air handling units, economizers, field controllers,supervisory controllers, actuators, temperature sensors, and otherdevices for controlling the temperature, humidity, airflow, or othervariable conditions within building 10. Lighting subsystem 442 caninclude any number of light fixtures, ballasts, lighting sensors,dimmers, or other devices configured to controllably adjust the amountof light provided to a building space. Security subsystem 438 caninclude occupancy sensors, video surveillance cameras, digital videorecorders, video processing servers, intrusion detection devices, accesscontrol devices and servers, or other security-related devices.

Still referring to FIG. 4, BMS controller 366 is shown to include acommunications interface 407 and a BMS interface 409. Interface 407 canfacilitate communications between BMS controller 366 and externalapplications (e.g., monitoring and reporting applications 422,enterprise control applications 426, remote systems and applications444, applications residing on client devices 448, etc.) for allowinguser control, monitoring, and adjustment to BMS controller 366 and/orsubsystems 428. Interface 407 can also facilitate communications betweenBMS controller 366 and client devices 448. BMS interface 409 canfacilitate communications between BMS controller 366 and buildingsubsystems 428 (e.g., HVAC, lighting security, lifts, powerdistribution, business, etc.).

Interfaces 407, 409 can be or include wired or wireless communicationsinterfaces (e.g., jacks, antennas, transmitters, receivers,transceivers, wire terminals, etc.) for conducting data communicationswith building subsystems 428 or other external systems or devices. Invarious embodiments, communications via interfaces 407, 409 can bedirect (e.g., local wired or wireless communications) or via acommunications network 446 (e.g., a WAN, the Internet, a cellularnetwork, etc.). For example, interfaces 407, 409 can include an Ethernetcard and port for sending and receiving data via an Ethernet-basedcommunications link or network. In another example, interfaces 407, 409can include a WiFi transceiver for communicating via a wirelesscommunications network. In another example, one or both of interfaces407, 409 can include cellular or mobile phone communicationstransceivers. In one embodiment, communications interface 407 is a powerline communications interface and BMS interface 409 is an Ethernetinterface. In other embodiments, both communications interface 407 andBMS interface 409 are Ethernet interfaces or are the same Ethernetinterface.

Still referring to FIG. 4, BMS controller 366 is shown to include aprocessing circuit 404 including a processor 406 and memory 408.Processing circuit 404 can be communicably connected to BMS interface409 and/or communications interface 407 such that processing circuit 404and the various components thereof can send and receive data viainterfaces 407, 409. Processor 406 can be implemented as a generalpurpose processor, an application specific integrated circuit (ASIC),one or more field programmable gate arrays (FPGAs), a group ofprocessing components, or other suitable electronic processingcomponents.

Memory 408 (e.g., memory, memory unit, storage device, etc.) can includeone or more devices (e.g., RAM, ROM, Flash memory, hard disk storage,etc.) for storing data and/or computer code for completing orfacilitating the various processes, layers and modules described in thepresent application. Memory 408 can be or include volatile memory ornon-volatile memory. Memory 408 can include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures described in the present application. According to anexemplary embodiment, memory 408 is communicably connected to processor406 via processing circuit 404 and includes computer code for executing(e.g., by processing circuit 404 and/or processor 406) one or moreprocesses described herein.

In some embodiments, BMS controller 366 is implemented within a singlecomputer (e.g., one server, one housing, etc.). In various otherembodiments BMS controller 366 can be distributed across multipleservers or computers (e.g., that can exist in distributed locations).Further, while FIG. 4 shows applications 422 and 426 as existing outsideof BMS controller 366, in some embodiments, applications 422 and 426 canbe hosted within BMS controller 366 (e.g., within memory 408).

Still referring to FIG. 4, memory 408 is shown to include an enterpriseintegration layer 410, an automated measurement and validation (AM&V)layer 412, a demand response (DR) layer 414, a fault detection anddiagnostics (FDD) layer 416, an integrated control layer 418, and abuilding subsystem integration later 420. Layers 410-420 can beconfigured to receive inputs from building subsystems 428 and other datasources, determine optimal control actions for building subsystems 428based on the inputs, generate control signals based on the optimalcontrol actions, and provide the generated control signals to buildingsubsystems 428. The following paragraphs describe some of the generalfunctions performed by each of layers 410-420 in BMS 400.

Enterprise integration layer 410 can be configured to serve clients orlocal applications with information and services to support a variety ofenterprise-level applications. For example, enterprise controlapplications 426 can be configured to provide subsystem-spanning controlto a graphical user interface (GUI) or to any number of enterprise-levelbusiness applications (e.g., accounting systems, user identificationsystems, etc.). Enterprise control applications 426 can also oralternatively be configured to provide configuration GUIs forconfiguring BMS controller 366. In yet other embodiments, enterprisecontrol applications 426 can work with layers 410-420 to optimizebuilding performance (e.g., efficiency, energy use, comfort, or safety)based on inputs received at interface 407 and/or BMS interface 409.

Building subsystem integration layer 420 can be configured to managecommunications between BMS controller 366 and building subsystems 428.For example, building subsystem integration layer 420 can receive sensordata and input signals from building subsystems 428 and provide outputdata and control signals to building subsystems 428. Building subsystemintegration layer 420 can also be configured to manage communicationsbetween building subsystems 428. Building subsystem integration layer420 translate communications (e.g., sensor data, input signals, outputsignals, etc.) across a plurality of multi-vendor/multi-protocolsystems.

Demand response layer 414 can be configured to optimize resource usage(e.g., electricity use, natural gas use, water use, etc.) and/or themonetary cost of such resource usage in response to satisfy the demandof building 10. The optimization can be based on time-of-use prices,curtailment signals, energy availability, or other data received fromutility providers, distributed energy generation systems 424, fromenergy storage 427 (e.g., hot TES 242, cold TES 244, etc.), or fromother sources. Demand response layer 414 can receive inputs from otherlayers of BMS controller 366 (e.g., building subsystem integration layer420, integrated control layer 418, etc.). The inputs received from otherlayers can include environmental or sensor inputs such as temperature,carbon dioxide levels, relative humidity levels, air quality sensoroutputs, occupancy sensor outputs, room schedules, and the like. Theinputs can also include inputs such as electrical use (e.g., expressedin kWh), thermal load measurements, pricing information, projectedpricing, smoothed pricing, curtailment signals from utilities, and thelike.

According to an exemplary embodiment, demand response layer 414 includescontrol logic for responding to the data and signals it receives. Theseresponses can include communicating with the control algorithms inintegrated control layer 418, changing control strategies, changingsetpoints, or activating/deactivating building equipment or subsystemsin a controlled manner. Demand response layer 414 can also includecontrol logic configured to determine when to utilize stored energy. Forexample, demand response layer 414 can determine to begin using energyfrom energy storage 427 just prior to the beginning of a peak use hour.

In some embodiments, demand response layer 414 includes a control moduleconfigured to actively initiate control actions (e.g., automaticallychanging setpoints) which minimize energy costs based on one or moreinputs representative of or based on demand (e.g., price, a curtailmentsignal, a demand level, etc.). In some embodiments, demand responselayer 414 uses equipment models to determine an optimal set of controlactions. The equipment models can include, for example, thermodynamicmodels describing the inputs, outputs, and/or functions performed byvarious sets of building equipment. Equipment models can representcollections of building equipment (e.g., subplants, chiller arrays,etc.) or individual devices (e.g., individual chillers, heaters, pumps,etc.).

Demand response layer 414 can further include or draw upon one or moredemand response policy definitions (e.g., databases, XML files, etc.).The policy definitions can be edited or adjusted by a user (e.g., via agraphical user interface) so that the control actions initiated inresponse to demand inputs can be tailored for the user's application,desired comfort level, particular building equipment, or based on otherconcerns. For example, the demand response policy definitions canspecify which equipment can be turned on or off in response toparticular demand inputs, how long a system or piece of equipment shouldbe turned off, what setpoints can be changed, what the allowable setpoint adjustment range is, how long to hold a high demand setpointbefore returning to a normally scheduled setpoint, how close to approachcapacity limits, which equipment modes to utilize, the energy transferrates (e.g., the maximum rate, an alarm rate, other rate boundaryinformation, etc.) into and out of energy storage devices (e.g., thermalstorage tanks, battery banks, etc.), and when to dispatch on-sitegeneration of energy (e.g., via fuel cells, a motor generator set,etc.).

Integrated control layer 418 can be configured to use the data input oroutput of building subsystem integration layer 420 and/or demandresponse later 414 to make control decisions. Due to the subsystemintegration provided by building subsystem integration layer 420,integrated control layer 418 can integrate control activities of thesubsystems 428 such that the subsystems 428 behave as a singleintegrated supersystem. In an exemplary embodiment, integrated controllayer 418 includes control logic that uses inputs and outputs from aplurality of building subsystems to provide greater comfort and energysavings relative to the comfort and energy savings that separatesubsystems could provide alone. For example, integrated control layer418 can be configured to use an input from a first subsystem to make anenergy-saving control decision for a second subsystem. Results of thesedecisions can be communicated back to building subsystem integrationlayer 420.

Integrated control layer 418 is shown to be logically below demandresponse layer 414. Integrated control layer 418 can be configured toenhance the effectiveness of demand response layer 414 by enablingbuilding subsystems 428 and their respective control loops to becontrolled in coordination with demand response layer 414. Thisconfiguration may advantageously reduce disruptive demand responsebehavior relative to conventional systems. For example, integratedcontrol layer 418 can be configured to assure that a demandresponse-driven upward adjustment to the setpoint for chilled watertemperature (or another component that directly or indirectly affectstemperature) does not result in an increase in fan energy (or otherenergy used to cool a space) that would result in greater total buildingenergy use than was saved at the chiller.

Integrated control layer 418 can be configured to provide feedback todemand response layer 414 so that demand response layer 414 checks thatconstraints (e.g., temperature, lighting levels, etc.) are properlymaintained even while demanded load shedding is in progress. Theconstraints can also include setpoint or sensed boundaries relating tosafety, equipment operating limits and performance, comfort, fire codes,electrical codes, energy codes, and the like. Integrated control layer418 is also logically below fault detection and diagnostics layer 416and automated measurement and validation layer 412. Integrated controllayer 418 can be configured to provide calculated inputs (e.g.,aggregations) to these higher levels based on outputs from more than onebuilding subsystem.

Automated measurement and validation (AM&V) layer 412 can be configuredto verify that control strategies commanded by integrated control layer418 or demand response layer 414 are working properly (e.g., using dataaggregated by AM&V layer 412, integrated control layer 418, buildingsubsystem integration layer 420, FDD layer 416, or otherwise). Thecalculations made by AM&V layer 412 can be based on building systemenergy models and/or equipment models for individual BMS devices orsubsystems. For example, AM&V layer 412 can compare a model-predictedoutput with an actual output from building subsystems 428 to determinean accuracy of the model.

Fault detection and diagnostics (FDD) layer 416 can be configured toprovide on-going fault detection for building subsystems 428, buildingsubsystem devices (i.e., building equipment), and control algorithmsused by demand response layer 414 and integrated control layer 418. FDDlayer 416 can receive data inputs from integrated control layer 418,directly from one or more building subsystems or devices, or fromanother data source. FDD layer 416 can automatically diagnose andrespond to detected faults. The responses to detected or diagnosedfaults can include providing an alert message to a user, a maintenancescheduling system, or a control algorithm configured to attempt torepair the fault or to work-around the fault.

FDD layer 416 can be configured to output a specific identification ofthe faulty component or cause of the fault (e.g., loose damper linkage)using detailed subsystem inputs available at building subsystemintegration layer 420. In other exemplary embodiments, FDD layer 416 isconfigured to provide “fault” events to integrated control layer 418which executes control strategies and policies in response to thereceived fault events. According to an exemplary embodiment, FDD layer416 (or a policy executed by an integrated control engine or businessrules engine) can shut-down systems or direct control activities aroundfaulty devices or systems to reduce energy waste, extend equipment life,or assure proper control response.

FDD layer 416 can be configured to store or access a variety ofdifferent system data stores (or data points for live data). FDD layer416 can use some content of the data stores to identify faults at theequipment level (e.g., specific chiller, specific AHU, specific terminalunit, etc.) and other content to identify faults at component orsubsystem levels. For example, building subsystems 428 can generatetemporal (i.e., time-series) data indicating the performance of BMS 400and the various components thereof. The data generated by buildingsubsystems 428 can include measured or calculated values that exhibitstatistical characteristics and provide information about how thecorresponding system or process (e.g., a temperature control process, aflow control process, etc.) is performing in terms of error from itssetpoint. These processes can be examined by FDD layer 416 to exposewhen the system begins to degrade in performance and alert a user torepair the fault before it becomes more severe.

Building Management System with Data Platform Services

Referring now to FIG. 5, a block diagram of another building managementsystem (BMS) 500 is shown, according to some embodiments. BMS 500 isconfigured to collect data samples from building subsystems 428 andgenerate raw timeseries data from the data samples. BMS 500 can processthe raw timeseries data using a variety of data platform services 520 togenerate optimized timeseries data (e.g., data rollups). The optimizedtimeseries data can be provided to various applications 530 and/orstored in local storage 514 or hosted storage 516. In some embodiments,BMS 500 separates data collection; data storage, retrieval, andanalysis; and data visualization into three different layers. Thisallows BMS 500 to support a variety of applications 530 that use theoptimized timeseries data and allows new applications 530 to reuse theexisting infrastructure provided by data platform services 520.

Before discussing BMS 500 in greater detail, it should be noted that thecomponents of BMS 500 can be integrated within a single device (e.g., asupervisory controller, a BMS controller, etc.) or distributed acrossmultiple separate systems or devices. For example, the components of BMS500 can be implemented as part of a METASYS® brand building automationsystem or a METASYS® Energy Management System (MEMS), as sold by JohnsonControls Inc. In other embodiments, some or all of the components of BMS500 can be implemented as part of a cloud-based computing systemconfigured to receive and process data from one or more buildingmanagement systems. In other embodiments, some or all of the componentsof BMS 500 can be components of a subsystem level controller (e.g., aHVAC controller), a subplant controller, a device controller (e.g., AHUcontroller 330, a chiller controller, etc.), a field controller, acomputer workstation, a client device, or any other system or devicethat receives and processes data from building equipment.

BMS 500 can include many of the same components as BMS 400, as describedwith reference to FIG. 4. For example, BMS 500 is shown to include a BMSinterface 502 and a communications interface 504. Interfaces 502-504 caninclude wired or wireless communications interfaces (e.g., jacks,antennas, transmitters, receivers, transceivers, wire terminals, etc.)for conducting data communications with building subsystems 428 or otherexternal systems or devices. Communications conducted via interfaces502-504 can be direct (e.g., local wired or wireless communications) orvia a communications network 446 (e.g., a WAN, the Internet, a cellularnetwork, etc.).

Communications interface 504 can facilitate communications between BMS500 and external applications (e.g., remote systems and applications444) for allowing user control, monitoring, and adjustment to BMS 500.Communications interface 504 can also facilitate communications betweenBMS 500 and client devices 448. BMS interface 502 can facilitatecommunications between BMS 500 and building subsystems 428. BMS 500 canbe configured to communicate with building subsystems 428 using any of avariety of building automation systems protocols (e.g., BACnet, Modbus,ADX, etc.). In some embodiments, BMS 500 receives data samples frombuilding subsystems 428 and provides control signals to buildingsubsystems 428 via BMS interface 502.

Building subsystems 428 can include building electrical subsystem 434,information communication technology (ICT) subsystem 436, securitysubsystem 438, HVAC subsystem 440, lighting subsystem 442,lift/escalators subsystem 432, and/or fire safety subsystem 430, asdescribed with reference to FIG. 4. In various embodiments, buildingsubsystems 428 can include fewer, additional, or alternative subsystems.For example, building subsystems 428 can also or alternatively include arefrigeration subsystem, an advertising or signage subsystem, a cookingsubsystem, a vending subsystem, a printer or copy service subsystem, orany other type of building subsystem that uses controllable equipmentand/or sensors to monitor or control building 10. In some embodiments,building subsystems 428 include waterside system 200 and/or airsidesystem 300, as described with reference to FIGS. 2-3. Each of buildingsubsystems 428 can include any number of devices, controllers, andconnections for completing its individual functions and controlactivities. Building subsystems 428 can include building equipment(e.g., sensors, air handling units, chillers, pumps, valves, etc.)configured to monitor and control a building condition such astemperature, humidity, airflow, etc.

Still referring to FIG. 5, BMS 500 is shown to include a processingcircuit 506 including a processor 508 and memory 510. Processor 508 canbe a general purpose or specific purpose processor, an applicationspecific integrated circuit (ASIC), one or more field programmable gatearrays (FPGAs), a group of processing components, or other suitableprocessing components. Processor 508 is configured to execute computercode or instructions stored in memory 510 or received from othercomputer readable media (e.g., CDROM, network storage, a remote server,etc.).

Memory 510 can include one or more devices (e.g., memory units, memorydevices, storage devices, etc.) for storing data and/or computer codefor completing and/or facilitating the various processes described inthe present disclosure. Memory 510 can include random access memory(RAM), read-only memory (ROM), hard drive storage, temporary storage,non-volatile memory, flash memory, optical memory, or any other suitablememory for storing software objects and/or computer instructions. Memory510 can include database components, object code components, scriptcomponents, or any other type of information structure for supportingthe various activities and information structures described in thepresent disclosure. Memory 510 can be communicably connected toprocessor 508 via processing circuit 506 and can include computer codefor executing (e.g., by processor 508) one or more processes describedherein. When processor 508 executes instructions stored in memory 510,processor 508 generally configures processing circuit 506 to completesuch activities.

Still referring to FIG. 5, BMS 500 is shown to include a data collector512. Data collector 512 is shown receiving data samples from buildingsubsystems 428 via BMS interface 502. In some embodiments, the datasamples include data values for various data points. The data values canbe measured or calculated values, depending on the type of data point.For example, a data point received from a temperature sensor can includea measured data value indicating a temperature measured by thetemperature sensor. A data point received from a chiller controller caninclude a calculated data value indicating a calculated efficiency ofthe chiller. Data collector 512 can receive data samples from multipledifferent devices within building subsystems 428.

The data samples can include one or more attributes that describe orcharacterize the corresponding data points. For example, the datasamples can include a name attribute defining a point name or ID (e.g.,“B1F4R2.T-Z”), a device attribute indicating a type of device from whichthe data samples is received (e.g., temperature sensor, humidity sensor,chiller, etc.), a unit attribute defining a unit of measure associatedwith the data value (e.g., ° F., ° C., kPA, etc.), and/or any otherattribute that describes the corresponding data point or providescontextual information regarding the data point. The types of attributesincluded in each data point can depend on the communications protocolused to send the data samples to BMS 500. For example, data samplesreceived via the ADX protocol or BACnet protocol can include a varietyof descriptive attributes along with the data value, whereas datasamples received via the Modbus protocol may include a lesser number ofattributes (e.g., only the data value without any correspondingattributes).

In some embodiments, each data sample is received with a timestampindicating a time at which the corresponding data value was measured orcalculated. In other embodiments, data collector 512 adds timestamps tothe data samples based on the times at which the data samples arereceived. Data collector 512 can generate raw timeseries data for eachof the data points for which data samples are received. Each timeseriescan include a series of data values for the same data point and atimestamp for each of the data values. For example, a timeseries for adata point provided by a temperature sensor can include a series oftemperature values measured by the temperature sensor and thecorresponding times at which the temperature values were measured.

Data collector 512 can add timestamps to the data samples or modifyexisting timestamps such that each data sample includes a localtimestamp. Each local timestamp indicates the local time at which thecorresponding data sample was measured or collected and can include anoffset relative to universal time. The local timestamp indicates thelocal time at the location the data point was measured at the time ofmeasurement. The offset indicates the difference between the local timeand a universal time (e.g., the time at the international date line).For example, a data sample collected in a time zone that is six hoursbehind universal time can include a local timestamp (e.g.,Timestamp=2016-03-18T14:10:02) and an offset indicating that the localtimestamp is six hours behind universal time (e.g., Offset=−6:00). Theoffset can be adjusted (e.g., +1:00 or −1:00) depending on whether thetime zone is in daylight savings time when the data sample is measuredor collected.

The combination of the local timestamp and the offset provides a uniquetimestamp across daylight saving time boundaries. This allows anapplication using the timeseries data to display the timeseries data inlocal time without first converting from universal time. The combinationof the local timestamp and the offset also provides enough informationto convert the local timestamp to universal time without needing to lookup a schedule of when daylight savings time occurs. For example, theoffset can be subtracted from the local timestamp to generate auniversal time value that corresponds to the local timestamp withoutreferencing an external database and without requiring any otherinformation.

In some embodiments, data collector 512 organizes the raw timeseriesdata. Data collector 512 can identify a system or device associated witheach of the data points. For example, data collector 512 can associate adata point with a temperature sensor, an air handler, a chiller, or anyother type of system or device. In various embodiments, data collectoruses the name of the data point, a range of values of the data point,statistical characteristics of the data point, or other attributes ofthe data point to identify a particular system or device associated withthe data point. Data collector 512 can then determine how that system ordevice relates to the other systems or devices in the building site. Forexample, data collector 512 can determine that the identified system ordevice is part of a larger system (e.g., a HVAC system) or serves aparticular space (e.g., a particular building, a room or zone of thebuilding, etc.). In some embodiments, data collector 512 uses or createsan entity graph when organizing the timeseries data. An example of suchan entity graph is described in greater detail with reference to FIG.10A.

Data collector 512 can provide the raw timeseries data to data platformservices 520 and/or store the raw timeseries data in local storage 514or hosted storage 516. As shown in FIG. 5, local storage 514 can be datastorage internal to BMS 500 (e.g., within memory 510) or other on-sitedata storage local to the building site at which the data samples arecollected. Hosted storage 516 can include a remote database, cloud-baseddata hosting, or other remote data storage. For example, hosted storage516 can include remote data storage located off-site relative to thebuilding site at which the data samples are collected.

Still referring to FIG. 5, BMS 500 is shown to include data platformservices 520. Data platform services 520 can receive the raw timeseriesdata from data collector 512 and/or retrieve the raw timeseries datafrom local storage 514 or hosted storage 516. Data platform services 520can include a variety of services configured to analyze and process theraw timeseries data. For example, data platform services 520 are shownto include a security service 522, an analytics service 524, an entityservice 526, and a timeseries service 528. Security service 522 canassign security attributes to the raw timeseries data to ensure that thetimeseries data are only accessible to authorized individuals, systems,or applications. Entity service 526 can assign entity information to thetimeseries data to associate data points with a particular system,device, or space. Timeseries service 528 and analytics service 524 cangenerate new optimized timeseries from the raw timeseries data.

In some embodiments, timeseries service 528 aggregates predefinedintervals of the raw timeseries data (e.g., quarter-hourly intervals,hourly intervals, daily intervals, monthly intervals, etc.) to generatenew optimized timeseries of the aggregated values. These optimizedtimeseries can be referred to as “data rollups” since they are condensedversions of the raw timeseries data. The data rollups generated bytimeseries service 528 provide an efficient mechanism for applications530 to query the timeseries data. For example, applications 530 canconstruct visualizations of the timeseries data (e.g., charts, graphs,etc.) using the pre-aggregated data rollups instead of the rawtimeseries data. This allows applications 530 to simply retrieve andpresent the pre-aggregated data rollups without requiring applications530 to perform an aggregation in response to the query. Since the datarollups are pre-aggregated, applications 530 can present the datarollups quickly and efficiently without requiring additional processingat query time to generate aggregated timeseries values.

In some embodiments, timeseries service 528 calculates virtual pointsbased on the raw timeseries data and/or the optimized timeseries data.Virtual points can be calculated by applying any of a variety ofmathematical operations (e.g., addition, subtraction, multiplication,division, etc.) or functions (e.g., average value, maximum value,minimum value, thermodynamic functions, linear functions, nonlinearfunctions, etc.) to the actual data points represented by the timeseriesdata. For example, timeseries service 528 can calculate a virtual datapoint (pointID₃) by adding two or more actual data points (pointID₁ andpointID₂) (e.g., pointID₃=pointID₁+pointID₂). As another example,timeseries service 528 can calculate an enthalpy data point (pointID₄)based on a measured temperature data point (pointID₅) and a measuredpressure data point (pointID₆) (e.g., pointID₄=enthalpy(pointID₅,pointID₆)). The virtual data points can be stored as optimizedtimeseries data.

Applications 530 can access and use the virtual data points in the samemanner as the actual data points. Applications 530 do not need to knowwhether a data point is an actual data point or a virtual data pointsince both types of data points can be stored as optimized timeseriesdata and can be handled in the same manner by applications 530. In someembodiments, the optimized timeseries data are stored with attributesdesignating each data point as either a virtual data point or an actualdata point. Such attributes allow applications 530 to identify whether agiven timeseries represents a virtual data point or an actual datapoint, even though both types of data points can be handled in the samemanner by applications 530.

In some embodiments, analytics service 524 analyzes the raw timeseriesdata and/or the optimized timeseries data to detect faults. Analyticsservice 524 can apply a set of fault detection rules to the timeseriesdata to determine whether a fault is detected at each interval of thetimeseries. Fault detections can be stored as optimized timeseries data.For example, analytics service 524 can generate a new timeseries withdata values that indicate whether a fault was detected at each intervalof the timeseries. The time series of fault detections can be storedalong with the raw timeseries data and/or optimized timeseries data inlocal storage 514 or hosted storage 516. These and other features ofanalytics service 524 and timeseries service 528 are described ingreater detail with reference to FIG. 6.

Still referring to FIG. 5, BMS 500 is shown to include severalapplications 530 including an energy management application 532,monitoring and reporting applications 534, and enterprise controlapplications 536. Although only a few applications 530 are shown, it iscontemplated that applications 530 can include any of a variety ofapplications configured to use the optimized timeseries data generatedby data platform services 520. In some embodiments, applications 530exist as a separate layer of BMS 500 (i.e., separate from data platformservices 520 and data collector 512). This allows applications 530 to beisolated from the details of how the optimized timeseries data aregenerated. In other embodiments, applications 530 can exist as remoteapplications that run on remote systems or devices (e.g., remote systemsand applications 444, client devices 448).

Applications 530 can use the optimized timeseries data to perform avariety data visualization, monitoring, and/or control activities. Forexample, energy management application 532 and monitoring and reportingapplication 534 can use the optimized timeseries data to generate userinterfaces (e.g., charts, graphs, etc.) that present the optimizedtimeseries data to a user. In some embodiments, the user interfacespresent the raw timeseries data and the optimized data rollups in asingle chart or graph. For example, a dropdown selector can be providedto allow a user to select the raw timeseries data or any of the datarollups for a given data point. Several examples of user interfaces thatcan be generated based on the optimized timeseries data are shown inFIGS. 15 and 17.

Enterprise control application 536 can use the optimized timeseries datato perform various control activities. For example, enterprise controlapplication 536 can use the optimized timeseries data as input to acontrol algorithm (e.g., a state-based algorithm, an extremum seekingcontrol (ESC) algorithm, a proportional-integral (PI) control algorithm,a proportional-integral-derivative (PID) control algorithm, a modelpredictive control (MPC) algorithm, a feedback control algorithm, etc.)to generate control signals for building subsystems 428. In someembodiments, building subsystems 428 use the control signals to operatebuilding equipment. Operating the building equipment can affect themeasured or calculated values of the data samples provided to BMS 500.Accordingly, enterprise control application 536 can use the optimizedtimeseries data as feedback to control the systems and devices ofbuilding subsystems 428.

Still referring to FIG. 5, BMS 500 is shown to include a dashboardlayout generator 518. Dashboard layout generator 518 is configured togenerate a layout for a user interface (i.e., a dashboard) visualizingthe timeseries data. In some embodiments, the dashboard layout is notitself a user interface, but rather a description which can be used byapplications 530 to generate the user interface. In some embodiments,the dashboard layout is a schema that defines the relative locations ofvarious widgets (e.g., charts, graphs, etc.) which can be rendered anddisplayed as part of the user interface. The dashboard layout can beread by a variety of different frameworks and can be used by a varietyof different rendering engines (e.g., a web browser, a pdf engine, etc.)or applications 530 to generate the user interface.

In some embodiments, the dashboard layout defines a grid having one ormore rows and one or more columns located within each row. The dashboardlayout can define the location of each widget at a particular locationwithin the grid. The dashboard layout can define an array of objects(e.g., JSON objects), each of which is itself an array. In someembodiments, the dashboard layout defines attributes or properties ofeach widget. For example, the dashboard layout can define the type ofwidget (e.g., graph, plain text, image, etc.). If the widget is a graph,the dashboard layout can define additional properties such as graphtitle, x-axis title, y-axis title, and the timeseries data used in thegraph. Dashboard layout generator 518 and the dashboard layouts aredescribed in greater detail with reference to FIGS. 12-17.

Timeseries and Analytics Data Platform Services

Referring now to FIG. 6, a block diagram illustrating timeseries service528 and analytics service 524 in greater detail is shown, according tosome embodiments. Timeseries service 528 is shown to include atimeseries web service 602, a job manager 604, and a timeseries storageinterface 616. Timeseries web service 602 is configured to interact withweb-based applications to send and/or receive timeseries data. In someembodiments, timeseries web service 602 provides timeseries data toweb-based applications. For example, if one or more of applications 530are web-based applications, timeseries web service 602 can provideoptimized timeseries data and raw timeseries data to the web-basedapplications. In some embodiments, timeseries web service 602 receivesraw timeseries data from a web-based data collector. For example, ifdata collector 512 is a web-based application, timeseries web service602 can receive data samples or raw timeseries data from data collector512.

Timeseries storage interface 616 is configured to interact with localstorage 514 and/or hosted storage 516. For example, timeseries storageinterface 616 can retrieve raw timeseries data from a local timeseriesdatabase 628 within local storage 514 or from a hosted timeseriesdatabase 636 within hosted storage 516. Timeseries storage interface 616can also store optimized timeseries data in local timeseries database628 or hosted timeseries database 636. In some embodiments, timeseriesstorage interface 616 is configured to retrieve jobs from a local jobqueue 630 within local storage 514 or from a hosted job queue 638 withinhosted storage 516. Timeseries storage interface 616 can also store jobswithin local job queue 630 or hosted job queue 638. Jobs can be createdand/or processed by job manager 604 to generate optimized timeseriesdata from the raw timeseries data.

Still referring to FIG. 6, job manager 604 is shown to include a sampleaggregator 608. Sample aggregator 608 is configured to generateoptimized data rollups from the raw timeseries data. For each datapoint, sample aggregator 608 can aggregate a set of data values havingtimestamps within a predetermined time interval (e.g., a quarter-hour,an hour, a day, etc.) to generate an aggregate data value for thepredetermined time interval. For example, the raw timeseries data for aparticular data point may have a relatively short interval (e.g., oneminute) between consecutive samples of the data point. Sample aggregator608 can generate a data rollup from the raw timeseries data byaggregating all of the samples of the data point having timestampswithin a relatively longer interval (e.g., a quarter-hour) into a singleaggregated value that represents the longer interval.

For some types of timeseries, sample aggregator 608 performs theaggregation by averaging all of the samples of the data point havingtimestamps within the longer interval. Aggregation by averaging can beused to calculate aggregate values for timeseries of non-cumulativevariables such as measured value. For other types of timeseries, sampleaggregator 608 performs the aggregation by summing all of the samples ofthe data point having timestamps within the longer interval. Aggregationby summation can be used to calculate aggregate values for timeseries ofcumulative variables such as the number of faults detected since theprevious sample.

Referring now to FIGS. 7A-7B, a block diagram 700 and a data table 750illustrating an aggregation technique which can be used by sampleaggregator 608 is shown, according to some embodiments. In FIG. 7A, adata point 702 is shown. Data point 702 is an example of a measured datapoint for which timeseries values can be obtained. For example, datapoint 702 is shown as an outdoor air temperature point and has valueswhich can be measured by a temperature sensor. Although a specific typeof data point 702 is shown in FIG. 7A, it should be understood that datapoint 702 can be any type of measured or calculated data point.Timeseries values of data point 702 can be collected by data collector512 and assembled into a raw data timeseries 704.

As shown in FIG. 7B, the raw data timeseries 704 includes a timeseriesof data samples, each of which is shown as a separate row in data table750. Each sample of raw data timeseries 704 is shown to include atimestamp and a data value. The timestamps of raw data timeseries 704are ten minutes and one second apart, indicating that the samplinginterval of raw data timeseries 704 is ten minutes and one second. Forexample, the timestamp of the first data sample is shown as2015-12-31T23:10:00 indicating that the first data sample of raw datatimeseries 704 was collected at 11:10:00 PM on Dec. 31, 2015. Thetimestamp of the second data sample is shown as 2015-12-31T23:20:01indicating that the second data sample of raw data timeseries 704 wascollected at 11:20:01 PM on Dec. 31, 2015. In some embodiments, thetimestamps of raw data timeseries 704 are stored along with an offsetrelative to universal time, as previously described. The values of rawdata timeseries 704 start at a value of 10 and increase by 10 with eachsample. For example, the value of the second sample of raw datatimeseries 704 is 20, the value of the third sample of raw datatimeseries 704 is 30, etc.

In FIG. 7A, several data rollup timeseries 706-714 are shown. Datarollup timeseries 706-714 can be generated by sample aggregator 608 andstored as optimized timeseries data. The data rollup timeseries 706-714include an average quarter-hour timeseries 706, an average hourlytimeseries 708, an average daily timeseries 710, an average monthlytimeseries 712, and an average yearly timeseries 714. Each of the datarollup timeseries 706-714 is dependent upon a parent timeseries. In someembodiments, the parent timeseries for each of the data rolluptimeseries 706-714 is the timeseries with the next shortest durationbetween consecutive timeseries values. For example, the parenttimeseries for average quarter-hour timeseries 706 is raw datatimeseries 704. Similarly, the parent timeseries for average hourlytimeseries 708 is average quarter-hour timeseries 706; the parenttimeseries for average daily timeseries 710 is average hourly timeseries708; the parent timeseries for average monthly timeseries 712 is averagedaily timeseries 710; and the parent timeseries for average yearlytimeseries 714 is average monthly timeseries 712.

Sample aggregator 608 can generate each of the data rollup timeseries706-714 from the timeseries values of the corresponding parenttimeseries. For example, sample aggregator 608 can generate averagequarter-hour timeseries 706 by aggregating all of the samples of datapoint 702 in raw data timeseries 704 that have timestamps within eachquarter-hour. Similarly, sample aggregator 608 can generate averagehourly timeseries 708 by aggregating all of the timeseries values ofaverage quarter-hour timeseries 706 that have timestamps within eachhour. Sample aggregator 608 can generate average daily timeseries 710 byaggregating all of the time series values of average hourly timeseries708 that have timestamps within each day. Sample aggregator 608 cangenerate average monthly timeseries 712 by aggregating all of the timeseries values of average daily timeseries 710 that have timestampswithin each month. Sample aggregator 608 can generate average yearlytimeseries 714 by aggregating all of the time series values of averagemonthly timeseries 712 that have timestamps within each year.

In some embodiments, the timestamps for each sample in the data rolluptimeseries 706-714 are the beginnings of the aggregation interval usedto calculate the value of the sample. For example, the first data sampleof average quarter-hour timeseries 706 is shown to include the timestamp2015-12-31T23:00:00. This timestamp indicates that the first data sampleof average quarter-hour timeseries 706 corresponds to an aggregationinterval that begins at 11:00:00 PM on Dec. 31, 2015. Since only onedata sample of raw data timeseries 704 occurs during this interval, thevalue of the first data sample of average quarter-hour timeseries 706 isthe average of a single data value (i.e., average(10)=10). The same istrue for the second data sample of average quarter-hour timeseries 706(i.e., average(20)=20).

The third data sample of average quarter-hour timeseries 706 is shown toinclude the timestamp 2015-12-31T23:30:00. This timestamp indicates thatthe third data sample of average quarter-hour timeseries 706 correspondsto an aggregation interval that begins at 11:30:00 PM on Dec. 31, 2015.Since each aggregation interval of average quarter-hour timeseries 706is a quarter-hour in duration, the end of the aggregation interval is11:45:00 PM on Dec. 31, 2015. This aggregation interval includes twodata samples of raw data timeseries 704 (i.e., the third raw data samplehaving a value of 30 and the fourth raw data sample having a value of40). Sample aggregator 608 can calculate the value of the third sampleof average quarter-hour timeseries 706 by averaging the values of thethird raw data sample and the fourth raw data sample (i.e., average(30,40)=35). Accordingly, the third sample of average quarter-hourtimeseries 706 has a value of 35. Sample aggregator 608 can calculatethe remaining values of average quarter-hour timeseries 706 in a similarmanner.

Still referring to FIG. 7B, the first data sample of average hourlytimeseries 708 is shown to include the timestamp 2015-12-31T23:00:00.This timestamp indicates that the first data sample of average hourlytimeseries 708 corresponds to an aggregation interval that begins at11:00:00 PM on Dec. 31, 2015. Since each aggregation interval of averagehourly timeseries 708 is an hour in duration, the end of the aggregationinterval is 12:00:00 AM on Jan. 1, 2016. This aggregation intervalincludes the first four samples of average quarter-hour timeseries 706.Sample aggregator 608 can calculate the value of the first sample ofaverage hourly timeseries 708 by averaging the values of the first fourvalues of average quarter-hour timeseries 706 (i.e., average(10, 20, 35,50)=28.8). Accordingly, the first sample of average hourly timeseries708 has a value of 28.8. Sample aggregator 608 can calculate theremaining values of average hourly timeseries 708 in a similar manner.

The first data sample of average daily timeseries 710 is shown toinclude the timestamp 2015-12-31T00:00:00. This timestamp indicates thatthe first data sample of average daily timeseries 710 corresponds to anaggregation interval that begins at 12:00:00 AM on Dec. 31, 2015. Sinceeach aggregation interval of the average daily timeseries 710 is a dayin duration, the end of the aggregation interval is 12:00:00 AM on Jan.1, 2016. Only one data sample of average hourly timeseries 708 occursduring this interval. Accordingly, the value of the first data sample ofaverage daily timeseries 710 is the average of a single data value(i.e., average(28.8)=28.8). The same is true for the second data sampleof average daily timeseries 710 (i.e., average(87.5)=87.5).

In some embodiments, sample aggregator 608 stores each of the datarollup timeseries 706-714 in a single data table (e.g., data table 750)along with raw data timeseries 704. This allows applications 530 toretrieve all of the timeseries 704-714 quickly and efficiently byaccessing a single data table. In other embodiments, sample aggregator608 can store the various timeseries 704-714 in separate data tableswhich can be stored in the same data storage device (e.g., the samedatabase) or distributed across multiple data storage devices. In someembodiments, sample aggregator 608 stores data timeseries 704-714 in aformat other than a data table. For example, sample aggregator 608 canstore timeseries 704-714 as vectors, as a matrix, as a list, or usingany of a variety of other data storage formats.

In some embodiments, sample aggregator 608 automatically updates thedata rollup timeseries 706-714 each time a new raw data sample isreceived. Updating the data rollup timeseries 706-714 can includerecalculating the aggregated values based on the value and timestamp ofthe new raw data sample. When a new raw data sample is received, sampleaggregator 608 can determine whether the timestamp of the new raw datasample is within any of the aggregation intervals for the samples of thedata rollup timeseries 706-714. For example, if a new raw data sample isreceived with a timestamp of 2016-01-01T00:52:00, sample aggregator 608can determine that the new raw data sample occurs within the aggregationinterval beginning at timestamp 2016-01-01T00:45:00 for averagequarter-hour timeseries 706. Sample aggregator 608 can use the value ofthe new raw data point (e.g., value=120) to update the aggregated valueof the final data sample of average quarter-hour timeseries 706 (i.e.,average(110, 120)=115).

If the new raw data sample has a timestamp that does not occur withinany of the previous aggregation intervals, sample aggregator 608 cancreate a new data sample in average quarter-hour timeseries 706. The newdata sample in average quarter-hour timeseries 706 can have a new datatimestamp defining the beginning of an aggregation interval thatincludes the timestamp of the new raw data sample. For example, if thenew raw data sample has a timestamp of 2016-01-01T01:00:11, sampleaggregator 608 can determine that the new raw data sample does not occurwithin any of the aggregation intervals previously established foraverage quarter-hour timeseries 706. Sample aggregator 608 can generatea new data sample in average quarter-hour timeseries 706 with thetimestamp 2016-01-01T01:00:00 and can calculate the value of the newdata sample in average quarter-hour timeseries 706 based on the value ofthe new raw data sample, as previously described.

Sample aggregator 608 can update the values of the remaining data rolluptimeseries 708-714 in a similar manner. For example, sample aggregator608 determine whether the timestamp of the updated data sample inaverage quarter-hour timeseries is within any of the aggregationintervals for the samples of average hourly timeseries 708. Sampleaggregator 608 can determine that the timestamp 2016-01-01T00:45:00occurs within the aggregation interval beginning at timestamp2016-01-01T00:00:00 for average hourly timeseries 708. Sample aggregator608 can use the updated value of the final data sample of averagequarter-hour timeseries 706 (e.g., value=115) to update the value of thesecond sample of average hourly timeseries 708 (i.e., average(65, 80,95, 115)=88.75). Sample aggregator 608 can use the updated value of thefinal data sample of average hourly timeseries 708 to update the finalsample of average daily timeseries 710 using the same technique.

In some embodiments, sample aggregator 608 updates the aggregated datavalues of data rollup timeseries 706-714 each time a new raw data sampleis received. Updating each time a new raw data sample is receivedensures that the data rollup timeseries 706-714 always reflect the mostrecent data samples. In other embodiments, sample aggregator 608 updatesthe aggregated data values of data rollup timeseries 706-714periodically at predetermined update intervals (e.g., hourly, daily,etc.) using a batch update technique. Updating periodically can be moreefficient and require less data processing than updating each time a newdata sample is received, but can result in aggregated data values thatare not always updated to reflect the most recent data samples.

In some embodiments, sample aggregator 608 is configured to cleanse rawdata timeseries 704. Cleansing raw data timeseries 704 can includediscarding exceptionally high or low data. For example, sampleaggregator 608 can identify a minimum expected data value and a maximumexpected data value for raw data timeseries 704. Sample aggregator 608can discard data values outside this range as bad data. In someembodiments, the minimum and maximum expected values are based onattributes of the data point represented by the timeseries. For example,data point 702 represents a measured outdoor air temperature andtherefore has an expected value within a range of reasonable outdoor airtemperature values for a given geographic location (e.g., between −20°F. and 110° F.). Sample aggregator 608 can discard a data value of 330for data point 702 since a temperature value of 330° F. is notreasonable for a measured outdoor air temperature.

In some embodiments, sample aggregator 608 identifies a maximum rate atwhich a data point can change between consecutive data samples. Themaximum rate of change can be based on physical principles (e.g., heattransfer principles), weather patterns, or other parameters that limitthe maximum rate of change of a particular data point. For example, datapoint 702 represents a measured outdoor air temperature and thereforecan be constrained to have a rate of change less than a maximumreasonable rate of change for outdoor temperature (e.g., five degreesper minute). If two consecutive data samples of the raw data timeseries704 have values that would require the outdoor air temperature to changeat a rate in excess of the maximum expected rate of change, sampleaggregator 608 can discard one or both of the data samples as bad data.

Sample aggregator 608 can perform any of a variety of data cleansingoperations to identify and discard bad data samples. Several examples ofdata cleansing operations which can be performed by sample aggregator608 are described in U.S. patent application Ser. No. 13/631,301 titled“Systems and Methods for Data Quality Control and Cleansing” and filedSep. 28, 2012, the entire disclosure of which is incorporated byreference herein. In some embodiments, sample aggregator 608 performsthe data cleansing operations for raw data timeseries 704 beforegenerating the data rollup timeseries 706-714. This ensures that rawdata timeseries 704 used to generate data rollup timeseries 706-714 doesnot include any bad data samples. Accordingly, the data rolluptimeseries 706-714 do not need to be re-cleansed after the aggregationis performed.

Referring again to FIG. 6, job manager 604 is shown to include a virtualpoint calculator 610. Virtual point calculator 610 is configured tocreate virtual data points and calculate timeseries values for thevirtual data points. A virtual data point is a type of calculated datapoint derived from one or more actual data points. In some embodiments,actual data points are measured data points, whereas virtual data pointsare calculated data points. Virtual data points can be used assubstitutes for actual sensor data when the sensor data desired for aparticular application does not exist, but can be calculated from one ormore actual data points. For example, a virtual data point representingthe enthalpy of a refrigerant can be calculated using actual data pointsmeasuring the temperature and pressure of the refrigerant. Virtual datapoints can also be used to provide timeseries values for calculatedquantities such as efficiency, coefficient of performance, and othervariables that cannot be directly measured.

Virtual point calculator 610 can calculate virtual data points byapplying any of a variety of mathematical operations or functions toactual data points or other virtual data points. For example, virtualpoint calculator 610 can calculate a virtual data point (pointID₃) byadding two or more actual data points (pointID₁ and pointID₂) (e.g.,pointID₃=pointID₁+pointID₂). As another example, virtual pointcalculator 610 can calculate an enthalpy data point (pointID₄) based ona measured temperature data point (pointID₅) and a measured pressuredata point (pointID₆) (e.g., pointID₄=enthalpy(pointID₅, pointID₆)). Insome instances, a virtual data point can be derived from a single actualdata point. For example, virtual point calculator 610 can calculate asaturation temperature (pointID₇) of a known refrigerant based on ameasured refrigerant pressure (pointID₈) (e.g.,pointID₇=T_(sat)(pointID₈)). In general, virtual point calculator 610can calculate the timeseries values of a virtual data point using thetimeseries values of one or more actual data points and/or thetimeseries values of one or more other virtual data points.

In some embodiments, virtual point calculator 610 uses a set of virtualpoint rules to calculate the virtual data points. The virtual pointrules can define one or more input data points (e.g., actual or virtualdata points) and the mathematical operations that should be applied tothe input data point(s) to calculate each virtual data point. Thevirtual point rules can be provided by a user, received from an externalsystem or device, and/or stored in memory 510. Virtual point calculator610 can apply the set of virtual point rules to the timeseries values ofthe input data points to calculate timeseries values for the virtualdata points. The timeseries values for the virtual data points can bestored as optimized timeseries data in local timeseries database 628and/or hosted timeseries database 636.

Virtual point calculator 610 can calculate virtual data points using thevalues of raw data timeseries 704 and/or the aggregated values of thedata rollup timeseries 706-714. In some embodiments, the input datapoints used to calculate a virtual data point are collected at differentsampling times and/or sampling rates. Accordingly, the samples of theinput data points may not be synchronized with each other, which canlead to ambiguity in which samples of the input data points should beused to calculate the virtual data point. Using the data rolluptimeseries 706-714 to calculate the virtual data points ensures that thetimestamps of the input data points are synchronized and eliminates anyambiguity in which data samples should be used.

Referring now to FIG. 8, several timeseries 800, 820, 840, and 860illustrating the synchronization of data samples resulting fromaggregating the raw timeseries data are shown, according to someembodiments. Timeseries 800 and 820 are raw data timeseries. Raw datatimeseries 800 has several raw data samples 802-810. Raw data sample 802is collected at time t₁; raw data sample 804 is collected at time t₂;raw data sample 806 is collected at time t₃; raw data sample 808 iscollected at time t₄; raw data sample 810 is collected at time t₅; andraw data sample 812 is collected at time t₆.

Raw data timeseries 820 also has several raw data samples 822, 824, 826,828, and 830. However, raw data samples, 822-830 are not synchronizedwith raw data samples 802-812. For example, raw data sample 822 iscollected before time t₁; raw data sample 824 is collected between timest₂ and t₃; raw data sample 826 is collected between times t₃ and t₄; rawdata sample 828 is collected between times t₄ and t₅; and raw datasample 830 is collected between times t₅ and t₆. The lack ofsynchronization between data samples 802-812 and raw data samples822-830 can lead to ambiguity in which of the data samples should beused together to calculate a virtual data point.

Timeseries 840 and 860 are data rollup timeseries. Data rolluptimeseries 840 can be generated by sample aggregator 608 by aggregatingraw data timeseries 800. Similarly, data rollup timeseries 860 can begenerated by sample aggregator 608 by aggregating raw data timeseries820. Both raw data timeseries 800 and 820 can be aggregated using thesame aggregation interval. Accordingly, the resulting data rolluptimeseries 840 and 860 have synchronized data samples. For example,aggregated data sample 842 is synchronized with aggregated data sample862 at time t₁′. Similarly, aggregated data sample 844 is synchronizedwith aggregated data sample 864 at time t₂′; aggregated data sample 846is synchronized with aggregated data sample 866 at time t₃′; andaggregated data sample 848 is synchronized with aggregated data sample868 at time t₄′.

The synchronization of data samples in data rollup timeseries 840 and860 allows virtual point calculator 610 to readily identify which of thedata samples should be used together to calculate a virtual point. Forexample, virtual point calculator 610 can identify which of the samplesof data rollup timeseries 840 and 860 have the same timestamp (e.g.,data samples 842 and 862, data samples 844 and 864, etc.). Virtual pointcalculator 610 can use two or more aggregated data samples with the sametimestamp to calculate a timeseries value of the virtual data point. Insome embodiments, virtual point calculator 610 assigns the sharedtimestamp of the input data samples to the timeseries value of thevirtual data point calculated from the input data samples.

Referring again to FIG. 6, job manager 604 is shown to include a weatherpoint calculator 612. Weather point calculator 612 is configured toperform weather-based calculations using the timeseries data. In someembodiments, weather point calculator 612 creates virtual data pointsfor weather-related variables such as cooling degree days (CDD), heatingdegree days (HDD), cooling energy days (CED), heating energy days (HED),and normalized energy consumption. The timeseries values of the virtualdata points calculated by weather point calculator 612 can be stored asoptimized timeseries data in local timeseries database 628 and/or hostedtimeseries database 636.

Weather point calculator 612 can calculate CDD by integrating thepositive temperature difference between the time-varying outdoor airtemperature T_(OA) and the cooling balance point T_(bC) for the buildingas shown in the following equation:

CDD=∫^(period) max{0,(T _(OA) −T _(bC))}dt

where period is the integration period. In some embodiments, the outdoorair temperature T_(OA) is a measured data point, whereas the coolingbalance point T_(bC) is a stored parameter. To calculate CDD for eachsample of the outdoor air temperature T_(OA), weather point calculator612 can multiply the quantity max{0,(T_(OA)−T_(bC))} by the samplingperiod Δt of the outdoor air temperature T_(OA). Weather pointcalculator 612 can calculate CED in a similar manner using outdoor airenthalpy E_(OA) instead of outdoor air temperature T_(OA). Outdoor airenthalpy E_(OA) can be a measured or virtual data point.

Weather point calculator 612 can calculate HDD by integrating thepositive temperature difference between a heating balance point T_(bH)for the building and the time-varying outdoor air temperature T_(OA) asshown in the following equation:

HDD=∫^(period) max{0,(T _(bH) −T _(OA))}dt

where period is the integration period. In some embodiments, the outdoorair temperature T_(OA) is a measured data point, whereas the heatingbalance point T_(bH) is a stored parameter. To calculate HDD for eachsample of the outdoor air temperature T_(OA), weather point calculator612 can multiply the quantity max{0, (T_(bH)−T_(OA))} by the samplingperiod Δt of the outdoor air temperature T_(OA). Weather pointcalculator 612 can calculate HED in a similar manner using outdoor airenthalpy E_(OA) instead of outdoor air temperature T_(OA).

In some embodiments, both virtual point calculator 610 and weather pointcalculator 612 calculate timeseries values of virtual data points.Weather point calculator 612 can calculate timeseries values of virtualdata points that depend on weather-related variables (e.g., outdoor airtemperature, outdoor air enthalpy, outdoor air humidity, outdoor lightintensity, precipitation, wind speed, etc.). Virtual point calculator610 can calculate timeseries values of virtual data points that dependon other types of variables (e.g., non-weather-related variables).Although only a few weather-related variables are described in detailhere, it is contemplated that weather point calculator 612 can calculatevirtual data points for any weather-related variable. Theweather-related data points used by weather point calculator 612 can bereceived as timeseries data from various weather sensors and/or from aweather service.

Still referring to FIG. 6, job manager 604 is shown to include a meterfault detector 614 and a scalable rules engine 606. Meter fault detector614 and scalable rules engine 606 are configured to detect faults intimeseries data. In some embodiments, meter fault detector 614 performsfault detection for timeseries data representing meter data (e.g.,measurements from a sensor), whereas scalable rules engine 606 performsfault detection for other types of timeseries data. Meter fault detector614 and scalable rules engine 606 can detect faults in the rawtimeseries data and/or the optimized timeseries data.

In some embodiments, meter fault detector 614 and scalable rules engine606 receive fault detection rules 620 and/or reasons 622 from analyticsservice 618. Fault detection rules 620 can be defined by a user via arules editor 624 or received from an external system or device viaanalytics web service 618. In various embodiments, fault detection rules620 and reasons 622 can be stored in rules database 632 and reasonsdatabase 634 within local storage 514 and/or rules database 640 andreasons database 642 within hosted storage 516. Meter fault detector 614and scalable rules engine 606 can retrieve fault detection rules 620from local storage 514 or hosted storage and use fault detection rules620 to analyze the timeseries data.

In some embodiments, fault detection rules 620 provide criteria that canbe evaluated by meter fault detector 614 and scalable rules engine 606to detect faults in the timeseries data. For example, fault detectionrules 620 can define a fault as a data value above or below a thresholdvalue. As another example, fault detection rules 620 can define a faultas a data value outside a predetermined range of values. The thresholdvalue and predetermined range of values can be based on the type oftimeseries data (e.g., meter data, calculated data, etc.), the type ofvariable represented by the timeseries data (e.g., temperature,humidity, energy consumption, etc.), the system or device that measuresor provides the timeseries data (e.g., a temperature sensor, a humiditysensor, a chiller, etc.), and/or other attributes of the timeseriesdata.

Meter fault detector 614 and scalable rules engine 606 can apply thefault detection rules 620 to the timeseries data to determine whethereach sample of the timeseries data qualifies as a fault. In someembodiments, meter fault detector 614 and scalable rules engine 606generate a fault detection timeseries containing the results of thefault detection. The fault detection timeseries can include a set oftimeseries values, each of which corresponds to a data sample of thetimeseries data evaluated by meter fault detector 614 and scalable rulesengine 606. In some embodiments, each timeseries value in the faultdetection timeseries includes a timestamp and a fault detection value.The timestamp can be the same as the timestamp of the corresponding datasample of the data timeseries. The fault detection value can indicatewhether the corresponding data sample of the data timeseries qualifiesas a fault. For example, the fault detection value can have a value of“Fault” if a fault is detected and a value of “Not in Fault” if a faultis not detected in the corresponding data sample of the data timeseries.The fault detection timeseries can be stored in local timeseriesdatabase 628 and/or hosted timeseries database 636 along with the rawtimeseries data and the optimized timeseries data.

Referring now to FIGS. 9A-9B, a block diagram and data table 900illustrating the fault detection timeseries is shown, according to someembodiments. In FIG. 9A, job manager 604 is shown receiving a datatimeseries 902 from local storage 514 or hosted storage 516. Datatimeseries 902 can be a raw data timeseries or an optimized datatimeseries. In some embodiments, data timeseries 902 is a timeseries ofvalues of an actual data point (e.g., a measured temperature). In otherembodiments, data timeseries 902 is a timeseries of values of a virtualdata point (e.g., a calculated efficiency). As shown in data table 900,data timeseries 902 includes a set of data samples. Each data sampleincludes a timestamp and a value. Most of the data samples have valueswithin the range of 65-66. However, three of the data samples havevalues of 42.

Job manager 604 can evaluate data timeseries 902 using a set of faultdetection rules 620 to detect faults in data timeseries 902. In variousembodiments, the fault detection can be performed by meter faultdetector 614 (e.g., if data timeseries 902 is meter data) or by scalablerules engine 606 (e.g., if data timeseries 902 is non-meter data). Insome embodiments, job manager 604 determines that the data sampleshaving values of 42 qualify as faults according to the fault detectionrules 620.

Job manager 604 can generate a fault detection timeseries 904 containingthe results of the fault detection. As shown in data table 900, faultdetection timeseries 904 includes a set of data samples. Like datatimeseries 902, each data sample of fault detection timeseries 904includes a timestamp and a value. Most of the values of fault detectiontimeseries 904 are shown as “Not in Fault,” indicating that no fault wasdetected for the corresponding sample of data timeseries 902 (i.e., thedata sample with the same timestamp). However, three of the data samplesin fault detection timeseries 904 have a value of “Fault,” indicatingthat the corresponding sample of data timeseries 902 qualifies as afault. As shown in FIG. 9A, job manager 604 can store fault detectiontimeseries 904 in local storage 514 (e.g., in local timeseries database628) and/or hosted storage 516 (e.g., in hosted timeseries database 636)along with the raw timeseries data and the optimized timeseries data.

Fault detection timeseries 904 can be used by BMS 500 to perform variousfault detection, diagnostic, and/or control processes. In someembodiments, fault detection timeseries 904 is further processed by jobmanager 604 to generate new timeseries derived from fault detectiontimeseries 904. For example, sample aggregator 608 can use faultdetection timeseries 904 to generate a fault duration timeseries. Sampleaggregator 608 can aggregate multiple consecutive data samples of faultdetection timeseries 904 having the same data value into a single datasample. For example, sample aggregator 608 can aggregate the first two“Not in Fault” data samples of fault detection timeseries 904 into asingle data sample representing a time period during which no fault wasdetected. Similarly, sample aggregator 608 can aggregate the final two“Fault” data samples of fault detection timeseries 904 into a singledata sample representing a time period during which a fault wasdetected.

In some embodiments, each data sample in the fault duration timeserieshas a fault occurrence time and a fault duration. The fault occurrencetime can be indicated by the timestamp of the data sample in the faultduration timeseries. Sample aggregator 608 can set the timestamp of eachdata sample in the fault duration timeseries equal to the timestamp ofthe first data sample in the series of data samples in fault detectiontimeseries 904 which were aggregated to form the aggregated data sample.For example, if sample aggregator 608 aggregates the first two “Not inFault” data samples of fault detection timeseries 904, sample aggregator608 can set the timestamp of the aggregated data sample to2015-12-31T23:10:00. Similarly, if sample aggregator 608 aggregates thefinal two “Fault” data samples of fault detection timeseries 904, sampleaggregator 608 can set the timestamp of the aggregated data sample to2015-12-31T23:50:00.

The fault duration can be indicated by the value of the data sample inthe fault duration timeseries. Sample aggregator 608 can set the valueof each data sample in the fault duration timeseries equal to theduration spanned by the consecutive data samples in fault detectiontimeseries 904 which were aggregated to form the aggregated data sample.Sample aggregator 608 can calculate the duration spanned by multipleconsecutive data samples by subtracting the timestamp of the first datasample of fault detection timeseries 904 included in the aggregationfrom the timestamp of the next data sample of fault detection timeseries904 after the data samples included in the aggregation.

For example, if sample aggregator 608 aggregates the first two “Not inFault” data samples of fault detection timeseries 904, sample aggregator608 can calculate the duration of the aggregated data sample bysubtracting the timestamp 2015-12-31T23:10:00 (i.e., the timestamp ofthe first “Not in Fault” sample) from the timestamp 2015-12-31T23:30:00(i.e., the timestamp of the first “Fault” sample after the consecutive“Not in Fault” samples) for an aggregated duration of twenty minutes.Similarly, if sample aggregator 608 aggregates the final two “Fault”data samples of fault detection timeseries 904, sample aggregator 608can calculate the duration of the aggregated data sample by subtractingthe timestamp 2015-12-31T23:50:00 (i.e., the timestamp of the first“Fault” sample included in the aggregation) from the timestamp2016-01-01T00:10:00 (i.e., the timestamp of the first “Not in Fault”sample after the consecutive “Fault” samples) for an aggregated durationof twenty minutes.

Referring now to FIG. 9C, a flow diagram illustrating how varioustimeseries can be generated, stored, and used in BMS 500 is shown,according to some embodiments. Data collector 512 is shown receivingdata samples from building subsystems 428. In some embodiments, the datasamples include data values for various data points. The data values canbe measured or calculated values, depending on the type of data point.For example, a data point received from a temperature sensor can includea measured data value indicating a temperature measured by thetemperature sensor. A data point received from a chiller controller caninclude a calculated data value indicating a calculated efficiency ofthe chiller. Data collector 512 can receive data samples from multipledifferent devices within building subsystems 428.

In some embodiments, each data sample is received with a timestampindicating a time at which the corresponding data value was measured orcalculated. In other embodiments, data collector 512 adds timestamps tothe data samples based on the times at which the data samples arereceived. Data collector 512 can generate raw timeseries data for eachof the data points for which data samples are received. Each timeseriescan include a series of data values for the same data point and atimestamp for each of the data values. For example, a timeseries for adata point provided by a temperature sensor can include a series oftemperature values measured by the temperature sensor and thecorresponding times at which the temperature values were measured.

Data collector 512 can add timestamps to the data samples or modifyexisting timestamps such that each data sample includes a localtimestamp. Each local timestamp indicates the local time at which thecorresponding data sample was measured or collected and can include anoffset relative to universal time. The local timestamp indicates thelocal time at the location the data point was measured at the time ofmeasurement. The offset indicates the difference between the local timeand a universal time (e.g., the time at the international date line).For example, a data sample collected in a time zone that is six hoursbehind universal time can include a local timestamp (e.g.,Timestamp=2016-03-18T14:10:02) and an offset indicating that the localtimestamp is six hours behind universal time (e.g., Offset=−6:00). Theoffset can be adjusted (e.g., +1:00 or −1:00) depending on whether thetime zone is in daylight savings time when the data sample is measuredor collected. Data collector 512 can provide the raw timeseries data tocontrol applications 536, data cleanser 644, and/or store the rawtimeseries data in timeseries storage 515 (i.e., local storage 514and/or hosted storage 516).

Data cleanser 644 can retrieve the raw data timeseries from timeseriesstorage 515 and cleanse the raw data timeseries. Cleansing the raw datatimeseries can include discarding exceptionally high or low data. Forexample, data cleanser 644 can identify a minimum expected data valueand a maximum expected data value for the raw data timeseries. Datacleanser 644 can discard data values outside this range as bad data. Insome embodiments, the minimum and maximum expected values are based onattributes of the data point represented by the timeseries. For example,an outdoor air temperature data point may have an expected value withina range of reasonable outdoor air temperature values for a givengeographic location (e.g., between −20° F. and 110° F.).

In some embodiments, data cleanser 644 identifies a maximum rate atwhich a data point can change between consecutive data samples. Themaximum rate of change can be based on physical principles (e.g., heattransfer principles), weather patterns, or other parameters that limitthe maximum rate of change of a particular data point. For example, anoutdoor air temperature data point can be constrained to have a rate ofchange less than a maximum reasonable rate of change for outdoortemperature (e.g., five degrees per minute). If two consecutive datasamples of the raw data timeseries have values that would require theoutdoor air temperature to change at a rate in excess of the maximumexpected rate of change, data cleanser 644 can discard one or both ofthe data samples as bad data.

Data cleanser 644 can perform any of a variety of data cleansingoperations to identify and discard bad data samples. Several examples ofdata cleansing operations which can be performed by data cleanser 644are described in U.S. patent application Ser. No. 13/631,301 titled“Systems and Methods for Data Quality Control and Cleansing” and filedSep. 28, 2012, the entire disclosure of which is incorporated byreference herein. In some embodiments, data cleanser 644 performs thedata cleansing operations for the raw data timeseries before sampleaggregator 608 generates the data rollup timeseries. This ensures thatthe raw data timeseries used to generate the data rollup timeseries doesnot include any bad data samples. Accordingly, the data rolluptimeseries do not need to be re-cleansed after the aggregation isperformed. Data cleanser 644 can provide the cleansed timeseries data tocontrol applications 536, sample aggregator 608, and/or store thecleansed timeseries data in timeseries storage 515.

Sample aggregator 608 can retrieve any data timeseries from timeseriesstorage 515 (e.g., a raw data timeseries, a cleansed data timeseries, adata rollup timeseries, a fault detection timeseries, etc.) and generatedata rollup timeseries based on the retrieved data timeseries. For eachdata point, sample aggregator 608 can aggregate a set of data valueshaving timestamps within a predetermined time interval (e.g., aquarter-hour, an hour, a day, etc.) to generate an aggregate data valuefor the predetermined time interval. For example, the raw timeseriesdata for a particular data point may have a relatively short interval(e.g., one minute) between consecutive samples of the data point. Sampleaggregator 608 can generate a data rollup from the raw timeseries databy aggregating all of the samples of the data point having timestampswithin a relatively longer interval (e.g., a quarter-hour) into a singleaggregated value that represents the longer interval.

For some types of timeseries, sample aggregator 608 performs theaggregation by averaging all of the samples of the data point havingtimestamps within the longer interval. Aggregation by averaging can beused to calculate aggregate values for timeseries of non-cumulativevariables such as measured value. For other types of timeseries, sampleaggregator 608 performs the aggregation by summing all of the samples ofthe data point having timestamps within the longer interval. Aggregationby summation can be used to calculate aggregate values for timeseries ofcumulative variables such as the number of faults detected since theprevious sample.

Sample aggregator 608 can generate any type of data rollup timeseriesincluding, for example, an average quarter-hour timeseries, an averagehourly timeseries, an average daily timeseries, an average monthlytimeseries, and an average yearly timeseries, or any other type of datarollup timeseries as described with reference to FIGS. 6-8. Each of thedata rollup timeseries may be dependent upon a parent timeseries. Insome embodiments, sample aggregator 608 updates the aggregated datavalues of data rollup timeseries each time a new raw data sample isreceived and/or each time the parent timeseries is updated. Sampleaggregator 608 can provide the data rollup timeseries to controlapplications 536, virtual point calculator 610, and/or store the datarollup timeseries in timeseries storage 515.

Virtual point calculator 610 can retrieve any timeseries from timeseriesstorage 515 and generate virtual point timeseries using the retrieveddata timeseries. Virtual point calculator can create virtual data pointsand calculate timeseries values for the virtual data points. A virtualdata point is a type of calculated data point derived from one or moreactual data points. In some embodiments, actual data points are measureddata points, whereas virtual data points are calculated data points.Virtual data points can be used as substitutes for actual sensor datawhen the sensor data desired for a particular application does notexist, but can be calculated from one or more actual data points. Forexample, a virtual data point representing the enthalpy of a refrigerantcan be calculated using actual data points measuring the temperature andpressure of the refrigerant. Virtual data points can also be used toprovide timeseries values for calculated quantities such as efficiency,coefficient of performance, and other variables that cannot be directlymeasured.

Virtual point calculator 610 can calculate virtual data points byapplying any of a variety of mathematical operations or functions toactual data points and/or other virtual data points. For example,virtual point calculator 610 can calculate a virtual data point(pointID₃) by adding two or more actual data points (pointID₁ andpointID₂) (e.g., pointID₃=pointID₁+pointID₂). As another example,virtual point calculator 610 can calculate an enthalpy data point(pointID₄) based on a measured temperature data point (pointID₅) and ameasured pressure data point (pointID₆) (e.g.,pointID₄=enthalpy(pointID₅, pointID₆)).

In some instances, a virtual data point can be derived from a singleactual data point. For example, virtual point calculator 610 cancalculate a saturation temperature (pointID₇) of a known refrigerantbased on a measured refrigerant pressure (pointID₈) (e.g.,pointID₇=T_(sat)(pointID₈)). In general, virtual point calculator 610can calculate the timeseries values of a virtual data point using thetimeseries values of one or more actual data points and/or thetimeseries values of one or more other virtual data points. In someembodiments, virtual point calculator 610 automatically updates thevalues of the virtual point timeseries whenever the source data used tocalculate the virtual data points is updated. Virtual point calculator610 can provide the virtual point timeseries to control applications536, scalable rules engine 606, and/or store the virtual pointtimeseries in timeseries storage 515.

Scalable rules engine 606 can retrieve any timeseries from timeseriesstorage 515 and generate fault detection timeseries using the retrieveddata timeseries. Scalable rules engine 606 can apply fault detectionrules to the timeseries data to determine whether each sample of thetimeseries data qualifies as a fault. In some embodiments, scalablerules engine 606 generates a fault detection timeseries containing theresults of the fault detection, as described with reference to FIGS.9A-9B. The fault detection timeseries can include a set of timeseriesvalues, each of which corresponds to a data sample of the timeseriesdata evaluated by scalable rules engine 606.

In some embodiments, each timeseries value in the fault detectiontimeseries includes a timestamp and a fault detection value. Thetimestamp can be the same as the timestamp of the corresponding datasample of the data timeseries. The fault detection value can indicatewhether the corresponding data sample of the data timeseries qualifiesas a fault. For example, the fault detection value can have a value of“Fault” if a fault is detected and a value of “Not in Fault” if a faultis not detected in the corresponding data sample of the data timeseries.In some embodiments, scalable rules engine 606 uses the fault detectiontimeseries to generate derivative timeseries such as a fault durationtimeseries, as described with reference to FIGS. 9A-9B. Scalable rulesengine 606 can provide the fault detection timeseries to controlapplications 536 and/or store the fault detection timeseries intimeseries storage 515.

Each of the data platform services 520 (e.g., data cleanser 644, sampleaggregator 608, virtual point calculator 610, scalable rules engine 606,etc.) can read any data timeseries from timeseries storage 515, generatenew data timeseries (e.g., cleansed data timeseries, data rolluptimeseries, virtual point timeseries, fault detection timeseries, etc.),and store the new data timeseries in timeseries storage 515. The newtimeseries can be stored alongside the original timeseries upon whichthe new timeseries is based such that the original timeseries does notneed to be updated. This allows multiple services to concurrently readthe same data timeseries from timeseries storage 515 without requiringany service to lock the timeseries.

The timeseries stored in timeseries storage 515 can affect each other.For example, the values of one or more first data timeseries can affectthe values of one or more second data timeseries based on the first datatimeseries. The first and second data timeseries can be any of the rawdata timeseries, cleansed data timeseries, data rollup timeseries,virtual point timeseries, fault detection timeseries, or any othertimeseries generated by data platform services 520. When the firsttimeseries is/are updated, the second timeseries can be automaticallyupdated by data platform services 520. Updates to the second timeseriescan trigger automatic updates to one or more third data timeseries basedon the second data timeseries. It is contemplated that any datatimeseries can be based on any other data timeseries and can beautomatically updated when the base data timeseries is updated.

In operation, a raw data timeseries can be written to timeseries storage515 by data collector 512 as the data are collected or received frombuilding subsystems 428. Subsequent processing by data cleanser 644,sample aggregator 608, virtual point calculator 610, and scalable rulesengine 606 can occur in any order. For example, data cleanser 644 cancleanse the raw data timeseries, a data rollup timeseries, a virtualpoint timeseries, and/or a fault detection timeseries. Similarly, sampleaggregator 608 can generate a data rollup timeseries using a raw datatimeseries, a cleansed data timeseries, another data rollup timeseries,a virtual point timeseries, and/or a fault detection timeseries. Virtualpoint calculator 610 can generate a virtual point timeseries based onone or more raw data timeseries, cleansed data timeseries, data rolluptimeseries, other virtual point timeseries, and/or fault detectiontimeseries. Scalable rules engine 606 can generate a fault detectiontimeseries using one or more raw data timeseries, cleansed datatimeseries, data rollup timeseries, virtual point timeseries, and/orother fault detection timeseries.

Referring again to FIG. 6, analytics service 524 is shown to include ananalytics web service 618, fault detection rules 620 and reasons 622, arules editor 624, and an analytics storage interface 626. Analytics webservice 618 is configured to interact with web-based applications tosend and/or receive fault detection rules 620 and reasons 622 andresults of data analytics. In some embodiments, analytics web service618 receives fault detection rules 620 and reasons 622 from a web-basedrules editor 624. For example, if rules editor 624 is a web-basedapplication, analytics web service 618 can receive rules 620 and reasons622 from rules editor 624. In some embodiments, analytics web service618 provides results of the analytics to web-based applications. Forexample, if one or more of applications 530 are web-based applications,analytics web service 618 can provide fault detection timeseries to theweb-based applications.

Analytics storage interface 626 is configured to interact with localstorage 514 and/or hosted storage 516. For example, analytics storageinterface 626 can retrieve rules 620 from local rules database 632within local storage 514 or from hosted rules database 640 within hostedstorage 516. Similarly, analytics storage interface 626 can retrievereasons 622 from local reasons database 634 within local storage 514 orfrom hosted reasons database 642 within hosted storage 516. Analyticsstorage interface 626 can also store rules 620 and reasons 622 withinlocal storage 514 and/or hosted storage 516.

Entity Graph

Referring now to FIG. 10A, an entity graph 1000 is shown, according tosome embodiments. In some embodiments, entity graph 1000 is generated orused by data collector 512, as described with reference to FIG. 5.Entity graph 1000 describes how a building is organized and how thedifferent systems and spaces within the building relate to each other.For example, entity graph 1000 is shown to include an organization 1002,a space 1004, a system 1006, a point 1008, and a timeseries 1009. Thearrows interconnecting organization 1002, space 1004, system 1006, point1008, and timeseries 1009 identify the relationships between suchentities. In some embodiments, the relationships are stored asattributes of the entity described by the attribute.

Organization 1002 is shown to include a contains descendants attribute1010, a parent ancestors attribute 1012, a contains attribute 1014, alocated in attribute 1016, an occupied by ancestors attribute 1018, andan occupies by attribute 1022. The contains descendants attribute 1010identifies any descendant entities contained within organization 1002.The parent ancestors attribute 1012 identifies any parent entities toorganization 1002. The contains attribute 1014 identifies any otherorganizations contained within organization 1002. The asterisk alongsidethe contains attribute 1014 indicates that organization 1002 can containany number of other organizations. The located in attribute 1016identifies another organization within which organization 1002 islocated. The number 1 alongside the located in attribute 1016 indicatesthat organization 1002 can be located in exactly one other organization.The occupies attribute 1022 identifies any spaces occupied byorganization 1002. The asterisk alongside the occupies attribute 1022indicates that organization 1002 can occupy any number of spaces.

Space 1004 is shown to include an occupied by attribute 1020, anoccupied by ancestors attribute 1018, a contains space descendantsattribute 1024, a located in ancestors attribute 1026, a contains spacesattribute 1028, a located in attribute 1030, a served by systemsattribute 1038, and a served by system descendants attribute 1034. Theoccupied by attribute 1020 identifies an organization occupied by space1004. The number 1 alongside the occupied by attribute 1020 indicatesthat space 1004 can be occupied by exactly one organization. Theoccupied by ancestors attribute 1018 identifies one or more ancestors toorganization 1002 that are occupied by space 1004. The asteriskalongside the occupied by ancestors attribute 1018 indicates that space1004 can be occupied by any number of ancestors.

The contains space descendants attribute 1024 identifies any descendantsto space 1004 that are contained within space 1004. The located inancestors attribute 1026 identifies any ancestors to space 1004 withinwhich space 1004 is located. The contains spaces attribute 1028identifies any other spaces contained within space 1004. The asteriskalongside the contains spaces attribute 1028 indicates that space 1004can contain any number of other spaces. The located in attribute 1030identifies another space within which space 1004 is located. The number1 alongside the located in attribute 1030 indicates that space 1004 canbe located in exactly one other space. The served by systems attribute1038 identifies any systems that serve space 1004. The asteriskalongside the served by systems attribute 1038 indicates that space 1004can be served by any number of systems. The served by system descendantsattribute 1034 identifies any descendent systems that serve space 1004.The asterisk alongside the served by descendant systems attribute 1034indicates that space 1004 can be served by any number of descendantsystems.

System 1006 is shown to include a serves spaces attribute 1036, a servesspace ancestors attribute 1032, a subsystem descendants attribute 1040,a part of ancestors attribute 1042, a subsystems attribute 1044, a partof attribute 1046, and a points attribute 1050. The serves spacesattribute 1036 identifies any spaces that are served by system 1006. Theasterisk alongside the serves spaces attribute 1036 indicates thatsystem 1006 can serve any number of spaces. The serves space ancestorsattribute 1032 identifies any ancestors to space 1004 that are served bysystem 1006. The asterisk alongside the serves ancestor spaces attribute1032 indicates that system 1006 can serve any number of ancestor spaces.

The subsystem descendants attribute 1040 identifies any subsystemdescendants of other systems contained within system 1006. The part ofancestors attribute 1042 identifies any ancestors to system 1006 thatsystem 1006 is part of. The subsystems attribute 1044 identifies anysubsystems contained within system 1006. The asterisk alongside thesubsystems attribute 1044 indicates that system 1006 can contain anynumber of subsystems. The part of attribute 1046 identifies any othersystems that system 1006 is part of. The number 1 alongside the part ofattribute 1046 indicates that system 1006 can be part of exactly oneother system. The points attribute 1050 identifies any data points thatare associated with system 1006. The asterisk alongside the pointsattribute 1050 indicates that any number of data points can beassociated with system 1006.

Point 1008 is shown to include a used by system attribute 1048. Theasterisk alongside the used by system attribute 1048 indicates thatpoint 1008 can be used by any number of systems. Point 1008 is alsoshown to include a used by timeseries attribute 1054. The asteriskalongside the used by timeseries attribute 1054 indicates that point1008 can be used by any number of timeseries (e.g., raw data timeseriesvirtual point timeseries, data rollup timeseries, etc.). For example,multiple virtual point timeseries can be based on the same actual datapoint 1008. In some embodiments, the used by timeseries attribute 1054is treated as a list of timeseries that subscribe to changes in value ofdata point 1008. When the value of point 1008 changes, the timeserieslisted in the used by timeseries attribute 1054 can be identified andautomatically updated to reflect the changed value of point 1008.

Timeseries 1009 is shown to include a uses point attribute 1052. Theasterisk alongside the uses point attribute 1052 indicates thattimeseries 1009 can use any number of actual data points. For example, avirtual point timeseries can be based on multiple actual data points. Insome embodiments, the uses point attribute 1052 is treated as a list ofpoints to monitor for changes in value. When any of the pointsidentified by the uses point attribute 1052 are updated, timeseries 1009can be automatically updated to reflect the changed value of the pointsused by timeseries 1009.

Timeseries 1009 is also shown to include a used by timeseries attribute1056 and a uses timeseries attribute 1058. The asterisks alongside theused by timeseries attribute 1056 and the uses timeseries attribute 1058indicate that timeseries 1009 can be used by any number of othertimeseries and can use any number of other timeseries. For example, botha data rollup timeseries and a virtual point timeseries can be based onthe same raw data timeseries. As another example, a single virtual pointtimeseries can be based on multiple other timeseries (e.g., multiple rawdata timeseries). In some embodiments, the used by timeseries attribute1056 is treated as a list of timeseries that subscribe to updates intimeseries 1009. When timeseries 1009 is updated, the timeseries listedin the used by timeseries attribute 1056 can be identified andautomatically updated to reflect the change to timeseries 1009.Similarly, the uses timeseries attribute 1058 can be treated as a listof timeseries to monitor for updates. When any of the timeseriesidentified by the uses timeseries attribute 1058 are updated, timeseries1009 can be automatically updated to reflect the updates to the othertimeseries upon which timeseries 1009 is based.

Referring now to FIG. 10B, an example of an entity graph 1060 for aparticular building management system is shown, according to someembodiments. Entity graph 1060 is shown to include an organization 1061(“ACME Corp”). Organization 1061 be a collection of people, a legalentity, a business, an agency, or other type of organization.Organization 1061 occupies space 1063 (“Milwaukee Campus”), as indicatedby the occupies attribute 1064. Space 1063 is occupied by organization1061, as indicated by the occupied by attribute 1062.

In some embodiments, space 1063 is a top level space in a hierarchy ofspaces. For example, space 1063 can represent an entire campus (i.e., acollection of buildings). Space 1063 can contain various subspaces(e.g., individual buildings) such as space 1065 (“Building 1”) and space1073 (“Building 2”), as indicated by the contains attributes 1068 and1080. Spaces 1065 and 1080 are located in space 1063, as indicated bythe located in attribute 1066. Each of spaces 1065 and 1073 can containlower level subspaces such as individual floors, zones, or rooms withineach building. However, such subspaces are omitted from entity graph1060 for simplicity.

Space 1065 is served by system 1067 (“ElecMainMeter1”) as indicated bythe served by attribute 1072. System 1067 can be any system that servesspace 1065 (e.g., a HVAC system, a lighting system, an electricalsystem, a security system, etc.). The serves attribute 1070 indicatesthat system 1067 serves space 1065. In entity graph 1060, system 1067 isshown as an electrical system having a subsystem 1069(“LightingSubMeter1”) and a subsystem 1071 (“PlugLoadSubMeter2”) asindicated by the subsystem attributes 1076 and 1078. Subsystems 1069 and1071 are part of system 1067, as indicated by the part of attribute1074.

Space 1073 is served by system 1075 (“ElecMainMeter2”) as indicated bythe served by attribute 1084. System 1075 can be any system that servesspace 1073 (e.g., a HVAC system, a lighting system, an electricalsystem, a security system, etc.). The serves attribute 1082 indicatesthat system 1075 serves space 1073. In entity graph 1060, system 1075 isshown as an electrical system having a subsystem 1077(“LightingSubMeter3”) as indicated by the subsystem attribute 1088.Subsystem 1077 is part of system 1075, as indicated by the part ofattribute 1086.

In addition to the attributes shown in FIG. 10B, entity graph 1060 caninclude “ancestors” and “descendants” attributes on each entity in thehierarchy. The ancestors attribute can identify (e.g., in a flat list)all of the entities that are ancestors to a given entity. For example,the ancestors attribute for space 1065 may identify both space 1063 andorganization 1061 as ancestors. Similarly, the descendants attribute canidentify all (e.g., in a flat list) of the entities that are descendantsof a given entity. For example, the descendants attribute for space 1065may identify system 1067, subsystem 1069, and subsystem 1071 asdescendants. This provides each entity with a complete listing of itsancestors and descendants, regardless of how many levels are included inthe hierarchical tree. This is a form of transitive closure.

In some embodiments, the transitive closure provided by the descendantsand ancestors attributes allows entity graph 1060 to facilitate simplequeries without having to search multiple levels of the hierarchicaltree. For example, the following query can be used to find all metersunder the Milwaukee Campus space 1063:

-   -   /Systems?$filter=(systemType eq Jci.Be.Data.SystemType‘Meter’)        and ancestorSpaces/any(a:a/name eq ‘Milwaukee Campus’)        and can be answered using only the descendants attribute of the        Milwaukee Campus space 1063. For example, the descendants        attribute of space 1063 can identify all meters that are        hierarchically below space 1063. The descendants attribute can        be organized as a flat list and stored as an attribute of space        1063. This allows the query to be served by searching only the        descendants attribute of space 1063 without requiring other        levels or entities of the hierarchy to be searched.

Referring now to FIG. 11, an object relationship diagram 1100 is shown,according to some embodiments. Relationship diagram 1100 is shown toinclude an entity template 1102, a point 1104, a timeseries 1106, and asample 1108. In some embodiments, entity template 1102, point 1104,timeseries 1106, and sample 1108 are stored as data objects withinmemory 510, local storage 514, and/or hosted storage 516. Relationshipdiagram 1100 illustrates the relationships between entity template 1102,point 1104, and timeseries 1106.

Entity template 1102 can include various attributes such as an IDattribute, a name attribute, a properties attribute, and a relationshipsattribute. The ID attribute can be provided as a text string andidentifies a unique ID for entity template 1102. The name attribute canalso be provided as a text string and identifies the name of entitytemplate 1102. The properties attribute can be provided as a vector andidentifies one or more properties of entity template 1102. Therelationships attribute can also be provided as a vector and identifiesone or more relationships of entity template 1102.

Point 1104 can include various attributes such as an ID attribute, anentity template ID attribute, a timeseries attribute, and a units IDattribute. The ID attribute can be provided as a text string andidentifies a unique ID for point 1104. The entity template ID attributecan also be provided as a text string and identifies the entity template1102 associated with point 1104 (e.g., by listing the ID attribute ofentity template 1102). Any number of points 1104 can be associated withentity template 1102. However, in some embodiments, each point 11104 isassociated with a single entity template 1102. The timeseries attributecan be provided as a text string and identifies any timeseriesassociated with point 1104 (e.g., by listing the ID string of anytimeseries 1106 associated with point 1104). The units ID attribute canalso be provided as a text string and identifies the units of thevariable quantified by point 1104.

Timeseries 1106 can include various attributes such as an ID attribute,a samples attribute, a transformation type attribute, and a units IDattribute. The ID attribute can be provided as a text string andidentifies a unique ID for timeseries 1106. The unique ID of timeseries1106 can be listed in the timeseries attribute of point 1104 toassociate timeseries 1106 with point 1104. Any number of timeseries 1106can be associated with point 1104. Each timeseries 1106 is associatedwith a single point 1104. The samples attribute can be provided as avector and identifies one or more samples associated with timeseries1106. The transformation type attribute identifies the type oftransformation used to generate timeseries 1106 (e.g., average hourly,average daily, average monthly, etc.). The units ID attribute can alsobe provided as a text string and identifies the units of the variablequantified by timeseries 1106.

Sample 1108 can include a timestamp attribute and a value attribute. Thetimestamp attribute can be provided in local time and can include anoffset relative to universal time. The value attribute can include adata value of sample 1108. In some instances, the value attribute is anumerical value (e.g., for measured variables). In other instances, thevalue attribute can be a text string such as “Fault” if sample 1108 ispart of a fault detection timeseries.

Dashboard Layouts

Referring now to FIG. 12, a block diagram illustrating the operation ofdashboard layout generator 518 is shown, according to some embodiments.Dashboard layout generator 518 is shown receiving points 1202, rawtimeseries data 1204, and optimized timeseries data 1206. Points 1202can include actual data points (e.g., measured data points), virtualdata points (e.g., calculated data points) or other types of data pointsfor which sample data is received at BMS 500 or calculated by BMS 500.Points 1202 can include instances of point 1104, as described withreference to FIG. 11. For example, each of points 1202 can include apoint ID, an entity template ID, an indication of one or more timeseriesassociated with the point, and a units ID. Raw timeseries data 1204 caninclude the raw timeseries data collected or generated by data collector512. Optimized timeseries data 1206 can include data rollup timeseries,cleansed timeseries, virtual point timeseries, weather point timeseries,fault detection timeseries, and/or other types of timeseries data whichcan be generated or processed by job manager 604.

Dashboard layout generator 518 is shown generating a dashboard layoutdescription 1208. In some embodiments, dashboard layout description 1208is a framework agnostic layout description which can be used to render auser interface (i.e., a dashboard layout) by a variety of differentrendering engines (e.g., a web browser, a PDF engine, etc.) and/orframeworks. Dashboard layout description 1208 is not itself a userinterface, but rather a schema which can be used by applications 530 andother frameworks to generate a user interface. Many different frameworksand applications 530 can read and use dashboard layout description 1208to generate a user interface according to the theming and sizing of theframework. In some embodiments, dashboard layout description 1208describes the dashboard layout using a grid of rows and columns.

Referring now to FIG. 13, a grid 1300 illustrating dashboard layoutdescription 1208 is shown. Grid 1300 is shown as a m×n grid including mrows and n columns. The intersections of the rows and columns defineparticular locations in grid 1300 at which widgets can be located. Forexample, grid 1300 is shown to include a text widget 1302 at theintersection of the first row and the second column. Grid 1300 alsoincludes a graph widget 1304 at the intersection of the second row andthe second column. In some embodiments, the locations of widgets 1302and 1304 are defined by the row and column indices of grid 1300. Forexample, dashboard layout description 1208 can define the location oftext widget 1302 by specifying that text widget 1302 is located at theintersection of the first row and the second column of grid 1300.Similarly, dashboard layout description 1208 can define the location ofgraph widget 1304 by specifying that graph widget 1304 is located at theintersection of the second row and the second column of grid 1300.

In some embodiments, dashboard layout description 1208 defines variousproperties for each widget. For example, widgets 1302 and 1304 can havea widget type property defining the type of the widget (e.g., text,graph, image, etc.). In some embodiments, widget 1302 has a textproperty defining the text displayed by widget 1302. Widget 1304 caninclude graph properties that define various attributes of the graph(e.g., graph title, x-axis title, y-axis title, etc.). In someembodiments, graph widget 1304 includes a property that defines one ormore timeseries of data displayed in widget 1304. The timeseries can bedifferent timeseries of the same data point (e.g., a raw datatimeseries, an average hourly timeseries, an average daily timeseries,etc.) or timeseries of different data points. In some embodiments, graphwidget 1304 includes properties that defines the widget name and a setof APIs that drive widget 1304 (e.g., service URLs or database URLs).

In some embodiments, dashboard layout description 1208 includes a toplevel dashboard element containing properties that apply to the entiredashboard layout. Such properties can include, for example, dashboardname, whether the widgets are collapsible, whether the dashboard iseditable, and the grid layout. The grid layout can be defined as anarray of objects (e.g., widgets), each of which is an array ofproperties. The dashboard layout can be static, dynamic, or userspecific. Static layouts can be used when the layout does not change.Dynamic layouts can be used to add more features to an existingdashboard. User specified layouts can be used to allow the dashboard tobe adjusted by the user (e.g., by adding or removing widgets).

Dashboard layout description 1208 can be used to drive various services.In some embodiments, dashboard layout description 1208 enables providinga user interface as a service. In this scenario, dashboard layoutgenerator 518 can provide a framework with predefined widgets. Theframework can read dashboard layout description 1208 and render the userinterface. Providing the user interface as a service allows new widgetsto be added to the predefined widgets. In other embodiments, dashboardlayout description 1208 enables providing data visualization as aservice.

Referring now to FIGS. 14-15, an example of a dashboard layoutdescription 1400 and a dashboard layout 1500 that can be generated fromdashboard layout description 1400 are shown, according to someembodiments. Referring particularly to FIG. 14, dashboard layoutdescription 1400 is shown to include several properties 1402 that applyto the entire dashboard layout 1500. Properties 1402 are shown toinclude a name of dashboard layout 1500 and properties defining whetherdashboard layout 1500 is collapsible, maximizable, and/or editable.

In some embodiments, dashboard layout description 1400 is described inJSON format. For example, dashboard layout description 1400 is shown toinclude a rows object 1404 and a columns object 1406 contained withinrows object 1404. Columns object 1406 contains two elements.Accordingly, dashboard layout description 1400 defines a layout thatincludes a single row and two columns within the row. Each of thecolumns includes a widget. For example, the first element of columnsobject 1406 includes a first widget object 1408, whereas the secondelement of columns object 1406 includes a second widget object 1410.

Widget object 1408 includes several properties 1412 defining variousattributes of widget object 1408. For example, widget object 1408 isshown to include properties defining a widget name (i.e., MEMS Meter), awidget type (i.e., spline) and a widget configuration. The spline typeindicates that widget object 1408 defines a line graph. The widgetconfiguration property includes several sub-properties 1414 definingattributes of the line graph. Sub-properties 1414 are shown to include atitle, an x-axis label (i.e., datetime), a y-axis label (i.e., KW), atoken API defining an API that drives widget object 1408, and a sampleAPI defining another API that drives widget object 1408. Sub-properties1414 also include a points property defining several timeseries that canbe displayed in widget object 1408.

Similarly, widget object 1410 includes several properties 1416 definingvarious attributes of widget object 1410. For example, widget object1410 is shown to include properties defining a widget name (i.e., MEMSMeter), a widget type (i.e., column) and a widget configuration. Thecolumn type indicates that widget object 1410 defines a bar graph. Thewidget configuration property includes several sub-properties 1418defining attributes of the bar graph. Sub-properties 1418 are shown toinclude a title, an x-axis label (i.e., datetime), a y-axis label (i.e.,KWH), a token API defining an API that drives widget object 1410, and asample API defining another API that drives widget object 1410.Sub-properties 1418 also include a points property defining severaltimeseries that can be displayed in widget object 1410.

Referring now to FIG. 15, dashboard layout 1500 is shown to include atitle 1502, a first widget 1504, and a second widget 1506. The text oftitle 1502 is defined by properties 1402, whereas first widget 1504 isdefined by widget object 1408, and second widget 1506 is defined bywidget object 1410. Dashboard layout 1500 includes a single row and twocolumns within the row. The first column includes first widget 1504,whereas the second column includes second widget 1506. Widget 1504 isshown to include the title 1508 “MEMS Meter” (defined by properties1412) and a dropdown selector 1512 which can be used to select any ofthe timeseries defined by sub-properties 1414. Similarly, widget 1506 isshown to include the title 1510 “MEMS Meter” (defined by properties1416) and a dropdown selector 1514 which can be used to select any ofthe timeseries defined by sub-properties 1418.

Referring now to FIGS. 16-17, another example of a dashboard layoutdescription 1600 and a dashboard layout 1700 that can be generated fromdashboard layout description 1600 are shown, according to someembodiments. Referring particularly to FIG. 16, dashboard layoutdescription 1600 is shown to include several properties 1602 that applyto the entire dashboard layout 1700. Properties 1602 are shown toinclude a name of dashboard layout 1700 and properties defining whetherdashboard layout 1700 is collapsible, maximizable, and/or editable.

In some embodiments, dashboard layout description 1600 is described inJSON format. For example, dashboard layout description 1600 is shown toinclude a rows object 1604. Rows object 1604 has two data elements, eachdefining a different row of dashboard layout 1700. The first element ofrows object 1604 contains a first a columns object 1606, whereas thesecond element of rows object 1604 contains a second columns object1607. Columns object 1606 has a single element which includes a firstwidget object 1608. However, columns object 1607 has two elements, eachof which includes a widget object (i.e., widget objects 1610 and 1620).Accordingly, dashboard layout description 1600 defines a layout thatincludes a first row with one column and a second row with two columns.The first row contains widget object 1608. The second row contains twowidget objects 1610 and 1620 in adjacent columns.

Widget object 1608 includes several properties 1612 defining variousattributes of widget object 1608. For example, widget object 1608 isshown to include properties defining a widget name (i.e., BTU Meter), awidget type (i.e., spline) and a widget configuration. The spline typeindicates that widget object 1608 defines a line graph. The widgetconfiguration property includes several sub-properties 1614 definingattributes of the line graph. Sub-properties 1614 are shown to include atitle, an x-axis label, a y-axis label, a token API defining an API thatdrives widget object 1608, and a sample API defining another API thatdrives widget object 1608. Sub-properties 1614 also include a pointsproperty defining several timeseries that can be displayed in widgetobject 1608.

Similarly, widget object 1610 includes several properties 1616 definingvarious attributes of widget object 1610. For example, widget object1610 is shown to include properties defining a widget name (i.e., Meter1), a widget type (i.e., spline) and a widget configuration. The splinetype indicates that widget object 1610 defines a line graph. The widgetconfiguration property includes several sub-properties 1618 definingattributes of the line graph. Sub-properties 1618 are shown to include atitle, an x-axis label, a y-axis label, a token API defining an API thatdrives widget object 1610, and a sample API defining another API thatdrives widget object 1610. Sub-properties 1618 also include a pointsproperty defining several timeseries that can be displayed in widgetobject 1610.

Widget object 1620 includes several properties 1622 defining variousattributes of widget object 1620. For example, widget object 1620 isshown to include properties defining a widget name (i.e., Meter 1), awidget type (i.e., spline) and a widget configuration. The spline typeindicates that widget object 1620 defines a line graph. The widgetconfiguration property includes several sub-properties 1624 definingattributes of the line graph. Sub-properties 1624 are shown to include atitle, an x-axis label, a y-axis label, a token API defining an API thatdrives widget object 1620, and a sample API defining another API thatdrives widget object 1620. Sub-properties 1624 also include a pointsproperty defining several timeseries that can be displayed in widgetobject 1620.

Referring now to FIG. 17, dashboard layout 1700 is shown to include atitle 1702, a first widget 1704, a second widget 1706, and a thirdwidget 1707. The text of title 1702 is defined by properties 1602. Thecontent of first widget 1704 is defined by widget object 1608; thecontent of second widget 1706 is defined by widget object 1610; and thecontent of third widget 1707 is defined by widget object 1620. Dashboardlayout 1700 includes two rows. The first row includes a single column,whereas the second row includes two columns. The first row includesfirst widget 1704, whereas the second row includes second widget 1706 inthe first column and third widget 1707 in the second column.

Widget 1704 is shown to include the title 1708 “BTU Meter” (defined byproperties 1612) and a dropdown selector 1712 which can be used toselect any of the timeseries defined by sub-properties 1614. Similarly,widget 1706 is shown to include the title 1710 “Meter 1” (defined byproperties 1616) and a dropdown selector 1714 which can be used toselect any of the timeseries defined by sub-properties 1618. Widget 1707is shown to include the title 1711 “Meter 1” (defined by properties1622) and a dropdown selector 1715 which can be used to select any ofthe timeseries defined by sub-properties 1624.

Energy Management System User Interfaces

Referring now to FIGS. 18-51, several user interfaces which can begenerated by building management system 500 are shown, according to anexemplary embodiment. In some embodiments, the user interfaces aregenerated by energy management application 532, monitoring and reportingapplication 534, enterprise control application 536, or otherapplications 530 that consume the optimized timeseries data generated bydata platform services 520. For example, the user interfaces can begenerated by a building energy management system which includes aninstance of energy management application 532. One example of such abuilding energy management system is the METASYS® Energy ManagementSystem (MEMS) by Johnson Controls Inc. The building energy managementsystem can be implemented as part of building management system 500(e.g., one of applications 530) or as a cloud-based application (e.g.,one of remote systems and applications 444) in communication withbuilding management system 500 via communications network 446 (e.g., theInternet, a LAN, a cellular network, etc.).

Referring now to FIG. 18, a login interface 1800 is shown, according toan exemplary embodiment. Login interface 1800 may be presented via a webbrowser and/or via an application running on a client device (e.g., adesktop computer, a laptop computer, a tablet, a smartphone, etc.). Auser can enter access credentials via login interface 1800 (e.g.,username 1802 and password 1804) to login to energy managementapplication 532. Access credentials entered via login interface 1800 maybe sent to an authentication server for authentication.

Overview Dashboard

Referring now to FIGS. 19-34, an overview dashboard 1900 for energymanagement application 532 is shown, according to an exemplaryembodiment. Overview dashboard 1900 may be presented after the user logsin and may be the first interface that the user sees after enteringaccess credentials 1802-1804. Overview dashboard 1900 is shown toinclude a navigation pane 1902 on the left side of dashboard 1900. Ahandle bar 1904 to the right of navigation pane 1902 (immediately to theright of search box 1906) may allow a user to view or hide navigationpane 1902. Overview dashboard 1900 may include a navigation tile 1908,shown in the upper right corner. When navigation tile 1908 is selected(e.g., clicked, hovered over, etc.) a pop-up window 2000 may appear(shown in FIG. 20). Pop-up window 2000 is shown to include a dashboardbutton 2002 which may allow the user to navigate to dashboard 1900, anda setting button 2004 which may allow the user to navigate to a setupinterface 3600 (described in greater detail below).

As shown in FIG. 19, navigation pane 1902 includes a portfolio tab 1910.Portfolio tab 1910 may include an outline or hierarchy of the facilitieswhich can be viewed and managed by the user. For example, portfolio tab1910 is shown to include a portfolio-level node 1912 indicating the nameof the portfolio or enterprise managed by energy management application532 (i.e., “ABC Corporation”) and two facility-level nodes 1914 and 1916indicating the facilities within the portfolio (i.e., “Ace Facility” and“Omega Facility”). In some embodiments, the portfolio is a set ofbuildings associated with the enterprise. When portfolio-level node 1912is selected, overview dashboard 1900 may display energy-relatedinformation for the portfolio. For example, overview dashboard 1900 isshown displaying a chart 1918 of energy use intensity (EUI) for thevarious facilities within the portfolio, an energy facts panel 1920 tothe right of chart 1918, and an energy consumption tracker 1922.

EUI chart 1918 may display the portfolio energy index as a function ofthe size of each facility. The dependent variable shown on the verticalaxis 1924 (kWh/sqft) may be calculated by summing the total energy usefor the facility and dividing by the size of the facility (e.g., squarefeet). A low EUI for a facility may indicate that the facility has abetter energy performance, whereas a high EUI for a facility mayindicate that the facility has a worse energy performance. The totalenergy use of the facility may be summed over a variety of differentintervals by selecting different time intervals. For example, a user canclick buttons 1926 above chart 1918 to select time intervals of oneweek, one month, three months, six months, one year, or a custom timeinterval (shown in FIG. 21). Hovering over a bar 1928 or 1930 in chart1918 may display a pop-up that indicates the value of the EUI and thename of the facility. In some embodiments, EUI chart 1918 includes anaverage portfolio EUI line 1932 which indicates the average EUI for allof the facilities. Average portfolio EUI line 1932 may allow a user toeasily compare the EUI of each facility to the portfolio average EUI.

In some embodiments, overview dashboard 1900 includes a chart of energydensity for the various facilities within the portfolio. Like EUI,energy density is an energy usage metric that is normalized to the areaof the facility. However, energy density may be calculated based on thechange in energy usage between consecutive samples rather than thecumulative energy usage over a time interval. In some embodiments,energy density is calculated by determining the change or delta inenergy usage (e.g., kWh) for the facility between consecutive samples ofthe energy usage and dividing the change or delta by the size of thefacility (e.g., square feet). For example, if the energy consumption ofa facility at 1:00 PM is 50 kWh and the energy consumption of thefacility at 2:00 PM is 70 kWh, the change or delta in energy consumptionbetween 1:00 PM and 2:00 PM would be 20 kWh. This delta (i.e., 20 kWh)can be divided by the area of the facility to determine the energydensity of the facility (e.g., kWh/sqft) for the time period between1:00 PM and 2:00 PM.

Throughout this disclosure, EUI is used as an example of an energy usagemetric for a facility. However, it should be understood that energydensity can be used in addition to or in place of EUI in any of the userinterfaces, analytics, or dashboards described herein. Any reference toEUI in the present disclosure can be replaced/supplemented with energydensity (or any other energy usage metric) without departing from theteachings of the present disclosure.

Energy facts panel 1920 may display the total amount of energy consumedby the portfolio during the time interval selected by the user. Forexample, energy facts panel 1920 is shown displaying an indication 1934that the portfolio consumed 37,152 kWh during the month of October 2015.In some embodiments, energy facts panel 1920 displays an indication 1936of the carbon footprint (i.e., CO2 emission) corresponding to the totalenergy consumption. Energy management application 532 may automaticallyconvert energy consumption to an amount of CO2 emission and display theamount of CO2 emission via energy facts panel 1920. Both EUI chart 1918and energy facts panel 1920 may be automatically updated in response toa user selecting a different time interval via EUI chart 1918.

Energy consumption tracker 1922 breaks down the total energy consumptioninto various commodities such as electricity and natural gas. Energyconsumption tracker 1922 may include a chart 1938 which indicates theamount of each commodity consumed by each facility during a particulartime interval. The time interval may be selected by the user usingbuttons 1940 displayed above the chart in energy consumption tracker1922. Similar to the time interval selection provided by EUI chart 1918,a user can select time intervals of one week, one month, three months,six months, one year, or a custom time interval.

As shown in FIG. 22, selecting or hovering over a bar 1942, 1944, 1946,or 1948 for a particular commodity in chart 1938 may display a pop-up2200 that indicates the amount of the commodity consumed by thecorresponding facility during the user-selected time interval. Forexample, hovering over gas bar 1942 within the Ace Facility row 1950 maydisplay the amount of gas consumption by the Ace Facility within thetime interval. Similarly, hovering over gas bar 1946 within the OmegaFacility row 1952 may display the amount of gas consumption by the OmegaFacility within the time interval. Gas consumption may be indicated inboth units of energy (e.g., kWh) and units of volume (e.g., cubic feet).Energy management application 532 may automatically convertcommodity-specific units provided by an energy utility (e.g., cubicfeet) to units of energy (e.g., kWh) so that the energy consumption canbe directly compared across various commodities. Pop-up 2200 may alsoindicate the percentage of the total energy consumption corresponding tothe selected commodity. For example, pop-up 2200 in FIG. 22 indicatesthat gas consumption contributed to 12% of the total energy consumptionfor the Ace Facility.

As shown in FIG. 23, selecting grid button 2302 to the right of timeinterval buttons 1940 may cause energy consumption tracker 1922 todisplay the energy consumption data 2304 in a grid format. Selectingexpand button 2306 in the upper right corner of energy consumptiontracker 1922 (i.e., the diagonal arrow) may cause energy consumptiontracker 1922 to expand to fill the entire screen. Similarly, expandbutton 2308 in the upper right corner of EUI panel 2310 may cause EUIchart 1918 to expand to fill the entire screen. This may allow the userto easily see detailed data for a long list of facilities which may notall fit within the compressed widgets (i.e., EUI chart 1918 and energyconsumption tracker 1922).

As shown in FIGS. 24-25, each of the widgets 2402 and 2404 shown indashboard 1900 may include a settings button 2406 and 2408 (shown as agear icon). Settings buttons 2406 and 2408 may allow the user to selectdifferent theme colors 2410 for the corresponding widget (shown in FIG.24) and screenshot/export the data from the widgets 2402 and 2404 invarious formats 2502 such as .svg, .png, .jpeg, .pdf, .csv, etc. (shownin FIG. 25).

As shown in FIG. 26, selecting a particular facility 1914 or 1916 viaportfolio tab 1910 may cause overview dashboard 1900 to displayenergy-related data for the selected facility 1914 or 1916. Theenergy-related data for a facility 1914 or 1916 may be similar to theenergy-related data for portfolio 1912. However, instead of breakingdown the energy-related data by facility, the data may be broken down byindividual buildings within the selected facility. For example, AceFacility 1914 is shown to include a single building 2602 titled “MainBuilding.” When building 2602 is selected, EUI chart 1918 and energyconsumption tracker 1922 may display energy consumption data for theselected building 2602. If additional buildings were included in theselected facility 1914, energy-related data for such buildings may alsobe displayed when the facility 1914 is selected.

As shown in FIG. 27, selecting a particular building 2602 via portfoliotab 1910 may cause overview dashboard 1900 to display energy-relateddata for the selected building 2602. Dashboard 1900 is shown to includefour widgets including an energy consumption widget 2702, an energydemand widget 2704, an energy consumption tracker widget 2706, and abuilding EUI widget 2708. Energy consumption widget 2702 may display theenergy consumption 2718 of the selected building at various timeintervals (e.g., weekly, daily, monthly, etc.). Each widget 2702-2708may include a time interval selector 2710, 2712, 2714, or 2716 whichallows the user to select a particular interval of data displayed ineach widget 2702-2708. Like the other time selectors 1926 and 1940, auser can click the buttons within the time interval selectors 2710-2716to select time intervals of one week, one month, three months, sixmonths, one year, or a custom time interval. In some embodiments, theone month interval is selected by default.

Energy demand widget 2704 may display an energy demand graph 2720 of theselected building at various time intervals. Bars 2722 displayed inenergy demand widget 2704 may indicate the current energy demand of theselected building. For example, FIG. 27 shows the energy demand for thebuilding broken down by days, where the energy demand for each day isrepresented by a bar 2722. In various embodiments, bars 2722 mayrepresent average energy demand or peak energy demand. The dots 2724displayed in energy demand widget 2704 represent the energy demand forthe previous time interval, prior to the time interval displayed ingraph 2720. For example, a monthly graph 2720 may display the currentenergy demand for each day of the month using bars 2722 and the previousenergy demand for each day of the previous month using dots 2724. Thisallows the user to easily compare energy demand for each day of twoconsecutive months. At other levels of granularity, the energy demandgraph 2720 may display yearly energy demand (each bar 2722 correspondingto a particular month), daily energy demand (each bar 2722 correspondingto a particular hour), etc.

Energy consumption tracker widget 2706 may display a chart 2726 thatindicates the amount of each commodity (e.g., gas 2728 and electricity2730) consumed by the selected building 2602. Selecting or hovering overa commodity 2728 or 2730 in chart 2726 may display a pop-up thatindicates the amount of the commodity consumed by building 2602 duringthe user-selected time interval. For example, hovering over the gas bar2728 may display the amount of gas consumption by building 2602 withinthe time interval. Gas consumption may be indicated in both units ofenergy (e.g., kWh) and units of volume (e.g., cubic feet). Energymanagement application 532 may automatically convert commodity-specificunits provided by an energy utility (e.g., cubic feet) to units ofenergy (e.g., kWh) so that the energy consumption can be directlycompared across various commodities. The pop-up may also indicate thepercentage of the total energy consumption corresponding to the selectedcommodity.

Building EUI widget 2708 may include an EUI graph 2732 indicating thebuilding's EUI. Building EUI 2736 may be calculated by dividing thetotal energy consumption of building 2602 by the size of building 2602(e.g., square feet). EUI graph 2732 may include an average facility EUIline 2734 which represents the average EUI for the facility 1914 whichincludes the selected building 2602. Average facility EUI line 2734 mayallow a user to easily compare the EUI of the selected building 2602 tothe facility average EUI.

As shown in FIG. 28, each widget 2802 (e.g., any of widgets 2702-2708)can be expanded to fill the entire screen by selecting expand button2804 in the upper right corner of widget 2802. The data shown in eachwidget 2802 can be displayed in grid format by selecting grid button2806 to the right of time interval selector 2808. Each widget 2802 mayinclude a settings button 2810 (shown as a gear icon). Settings button2810 may allow the user to select different theme colors for thecorresponding widget 2802 and screenshot/export the data from widget2802 in various formats such as .svg, .png, .jpeg, .pdf, .csv, etc., aspreviously described.

In some embodiments, selecting a bar 2812 or other graphic representingdata from a particular time interval causes graph 2814 to display theselected data with an increased level of granularity. For example, FIG.29 shows a bar chart 2902 indicating the weekly energy consumption ofthe Main Building 2602 with each bar 2904, 2906, 2908, 2910, and 2912representing the energy consumption during a particular day. Selectingone of bars 2904-2912 in chart 2902 may cause the energy consumption forthe selected day to be broken down by hour within the day (shown in FIG.30). For example, FIG. 30 shows a bar chart 3002 with a bar 3004 foreach hour of the day. Selecting one of bars 3004 in chart 3002 may causethe energy consumption for the selected hour to be broken down evenfurther (e.g., by fifteen minute intervals, by five minute intervals,etc.) within the hour (shown in FIG. 31). For example, FIG. 31 shows abar chart 3102 with a bar 3104, 3106, 3108, and 3110 for each fifteenminute interval within the selected hour. It is contemplated that theenergy consumption data can be displayed at any level of granularity andthat the user can transition between the different levels of granularityby clicking bars 2904-2912, 3004, and/or 3104-3110 within charts 2902,3002, and 3102.

As shown in FIGS. 32-33, a user can select specific ranges of datawithin each chart 3202 to zoom in on the selected range 3204 of data.For example, suppose a user wants to zoom in on the data from October5^(th) to October 28^(th). The user can click within a chart 3202 anddrag the mouse cursor to draw a box 3206 around the desired range 3204of data (shown in FIG. 32). Once the desired range 3204 of data isselected, chart 3202 may be automatically updated to display only theuser-selected range 3204 of data (shown in FIG. 33). Selecting the resetzoom button 3302 may cause chart 3202 to return to the previous view.

In some embodiments, overview dashboard 1900 is configured to allow auser to navigate portfolio 1910 of buildings without requiring use ofthe navigation pane 1902. For example, navigation pane 1902 can becollapsed (i.e., hidden) by clicking handle bar 1904 to the right ofsearch box 1906. When navigation pane 1902 is hidden, the user can clickan item in hierarchical string 3304 at the top of overview tab 3306(i.e., the string “ABC Corporation>Ace Facility>Main Building” shown inFIG. 33) to select the corresponding enterprise, facility, or building.Hierarchical string 3304 may be updated to show the lowest level of thehierarchy currently selected and any higher levels of the hierarchy thatcontain the selected lower level. For example, when Main Building 2602is selected, hierarchical string 3304 may include the full string “ABCCorporation>Ace Facility>Main Building.” However, if Ace Facility 1914is selected, hierarchical string 3304 may be updated to show only “ABCCorporation>Ace Facility.”

As shown in FIG. 34, navigation pane 1902 includes a meter tab 3402.When meter tab 3402 is selected, a user can expand the hierarchy 3404shown in navigation pane 1902 to show various energy meters 3406 and3408 located within each of the buildings. For example, the MainBuilding 2602 is shown to include a floor 3410 (i.e., Floor 1) whichincludes a “Main Electric Meter” 3406 and a “Main Gas Meter” 3408.Selecting any of the meters 3406-3408 in meter tab 3402 may causeoverview dashboard 1900 to display detailed meter data for the selectedmeter.

The meter data is shown to include energy consumption data which may bedisplayed in an energy consumption widget 3412, and energy demand datawhich may be displayed in an energy demand widget 3414. Each widget3412-3414 may include a time interval selector 3416 or 3418 which allowsthe user to select a particular interval of data displayed in eachwidget 3412-3414. Like the other time selectors 1926, 1940, and2710-2716, a user can click the buttons within time interval selectors3414-3416 to select time intervals of one week, one month, three months,six months, one year, or a custom time interval. In some embodiments,the one month interval is selected by default.

Energy consumption widget 3412 may display the energy consumptionmeasured by the selected meter 3406 at various time intervals (e.g.,weekly, daily, monthly, etc.). Energy consumption widget 3412 is shownto include a total current energy consumption 3420 for the selected timeinterval 3424 and the previous total energy consumption 3422 for aprevious time interval 3426. In some embodiments, the previous timeinterval 3426 is the same month (or any other duration selected via timeinterval selector 3416) from a previous year (or any other time intervallonger than the selected time interval). For example, the current timeinterval 3424 is shown as October 2015, and the previous time interval3426 is shown as October 2014. By comparing the energy consumptionduring the same months of different years, changes in energy consumptiondue to weather differences can be reduced so that the comparison is moremeaningful. Energy consumption widget 3412 may display an amount 3428 bywhich the energy consumption has increased or decreased (e.g., a percentchange) from the previous time interval 3426 to the current timeinterval 3424.

Energy demand widget 3414 may display the energy demand measured by theselected meter 3406 at various time intervals. Energy demand widget 3414is shown to include a graph 3440. The bars 3430 displayed in graph 3440may indicate the current energy demand measured by the selected meter3406. For example, FIG. 34 shows the energy demand for building 2602broken down by days, where the energy demand for each day is representedby a bar 3430 in graph 3440. In various embodiments, bars 3430 mayrepresent average energy demand or peak energy demand. Dots 3432displayed in graph 3440 represent the energy demand for thecorresponding time period of the previous time interval, prior to thetime interval displayed in graph 3440. For example, a monthly graph 3440may display the current energy demand for each day of the month usingbars 3430 and the previous energy demand for each day of the previousmonth using dots 3432. This allows the user to easily compare energydemand for each day of two consecutive months. At other levels ofgranularity, energy demand graph 3440 may display yearly energy demand(each bar 3430 and dot 3432 corresponding to a particular month), dailyenergy demand (each bar 3430 and dot 3432 corresponding to a particularhour), etc.

Referring now to FIG. 35 a flowchart of a process 3500 for configuringenergy management application 532 is shown, according to an exemplaryembodiment. Process 3500 is shown to include defining a space tree (step3502), defining a data source (step 3504), testing a connection to theADX (step 3506), discovering data points (step 3508), mapping datapoints (step 3510), updating point attributes if required (step 3512),syncing with the data platform (step 3514), fetching historic data forthe selected data points (step 3516), and mapping points to a space treeto show the data on the dashboard (step 3518).

Setup Interface

Referring now to FIGS. 36-49, a setup interface 3600 which may begenerated by energy management application 532 is shown, according to anexemplary embodiment. In some embodiments, setup interface 3600 isdisplayed in response to a user selecting settings button 2004 inoverview dashboard 1900 (shown in FIG. 20). Setup interface 3600 isshown to include various tiles 3602-3626 which correspond to differenttypes of configurable settings. For example, setup interface is shown toinclude a spaces tile 3602, a data sources tile 3604, a meterconfiguration tile 3606, a tenant tile 3608, a notification tile 3610, apoints tile 3612, a baseline tile 3614, a degree days tile 3616, afaults tile 3618, a tariff tile 3620, a users tile 3622, a schedule tile3624, and an information tile 3626. Tiles 3602-3626 may be highlighted,marked, colored, or otherwise altered to indicate that the correspondingsettings require configuration before overview dashboard 1900 willdisplay meaningful data. For example, spaces tile 3602, data sourcestile 3604, and meter configuration tile 3606 are shown with markings3628 in FIG. 26 to indicate that further configuration of the spaces,data sources, and meters used by energy management application 532 isrequired.

As shown in FIGS. 36-39, selecting spaces tile 3602 may display a spacesetup interface 3700. Space setup interface 3700 is shown to include aspace tree 3702. Space tree 3702 may include the hierarchy 3404 ofspaces shown in navigation pane 1902 of dashboard 1900. Spaces mayinclude, for example, portfolios 3704, facilities 3706-3708, buildings3710-3712, floors 3714-3716, zones, rooms, or other types of spaces atany level of granularity. A user can add spaces to space tree 3702 byselecting the plus button 3718 or remove spaces from space tree 3702 byselecting the trash button 3720. Spaces can also be added by uploading adata file 3730 (e.g., an Excel file) which defines space tree 3702.

Details of the selected space can be specified via space setup interface3700. For example, selecting portfolio 3704 “ABC Corporation” may allowa user to enter details of portfolio 3704 such as portfolio name 3722, adate format 3724, default units 3726, and a logo 3728 (shown in FIG.36). Selecting a facility 3706-3708 may allow a user to enter details ofthe facility such as the facility name 3732, address 3734, city 3736,state, country 3738, zip code 3740, latitude 3742, and longitude 3744(shown in FIG. 37). Selecting a building 3802 may allow a user to enterdetails of building 3802 such as the building name 3804, the gross floorarea 3806, and the number of occupants 3808 (shown in FIG. 38). Floorarea 3806 may be used by energy management application 532 to calculateEUI, as previously described. Selecting a floor 3902 may allow a user toenter details of the floor 3902 such as the floor name 3904 and thefloor area 3906 (shown in FIG. 39).

As shown in FIG. 40, selecting data sources tile 3604 may display a datasources setup interface 4000. Data sources setup interface 4000 may beused to define various data sources 4004 used by energy managementapplication 532. For example, a user can define a new data source byselecting a data source type (e.g., BACnet, CSV, FX, METASYS, etc.) viadata source type dropdown 4002. Other attributes of the data source canalso be specified via data sources setup interface 4000. Such attributesmay include, for example, the data source name 4006, server IP 4008,database path 4010, time zone 4012, username 4014, and password 4016.Selecting enable box 4018 may enable the data source. Selecting addbutton 4020 may add the data source to the list of data sources shown inchart 4030 at the bottom of interface 4000. After a data source has beenadded, selecting test connection button 4022 may test whether the datasource is online and properly configured.

As shown in FIG. 41, data sources setup interface 4000 may include adata mapping tab 4102. Dropdown selector 4104 allows a user to select aparticular data source (e.g., “ADX Mumbai”). After selecting a datasource, a user can click discover button 4106 to populate points tree4108 for the data source. Populating points tree 4108 may be performedautomatically by energy management application 532. For example, energymanagement application 532 may send a command to the ADX to fetch thedata points in response to a user clicking discover button 4106. The“All meters” button 4110, “All points” button 4112, and “Unmappedpoints” button 4114 may be used to filter the points by type, mappingstatus, and/or other attributes. Each button 4110-4114 can be toggledon/off to define a variety of different filters. For example, all metersbutton 4110 and unmapped points button 4114 can both be selected to viewonly unmapped meters. Similarly, all points button 4112 and unmappedpoints button 4114 can be selected to view all unmapped points.

As shown in FIGS. 42-44, point mapping may be performed by dragging anddropping points from points tree 4108 onto the window 4200 to the rightof points tree 4108. Any number of points can be mapped by simplydragging and dropping (shown in FIG. 42). Attributes 4302 of the mappeddata points 4304 may be displayed (shown in FIG. 43). Mapped data points4304 can be individually selected and deleted by checking check boxes4306 next to mapped data points 4304 and selecting “delete mapping”button 4308. Attributes 4302 of a mapped data point 4304 can be editedby clicking on the data point 4304. For example, selecting a data point4304 may cause a point configuration pop-up 4400 to be displayed (shownin FIG. 44), which allows the user to change the attributes 4302 of thedata point 4304 such as units, minimum value, maximum value, point name,etc. After the data points 4304 have been mapped, the user can click the“Sync” button 4310 (shown in FIG. 43) to synchronize the mapped datapoints 4304 with the data platform (e.g., data platform services 520).

As shown in FIG. 45, data sources setup interface 4000 may include ahistorical data tab 4502. Historical data tab 4502 allows a user toselect a data source 4504 and request a list of data points 4508 mappedto the data source (e.g., by clicking request button 4506). A user canenter a time interval (e.g., a range of dates) into date fields 4510 andclick submit button 4512 to request historical data for the selecteddata points for the user-specified time interval.

As shown in FIG. 46, selecting meter configuration tile 3606 may displaya meter configuration interface 4600. Meter configuration interface 4600is shown to include a points tree 4602, a meter distribution tree 4604,and a system details panel 4606. Points tree 4602 includes a dropdownselector 4608 which allows a user to specify a data source (e.g., ADXMumbai) and display a list of points 4610 associated with the datasource. List of points 4610 can be filtered to show only meters byselecting “All meters” button 4612 and/or all points by selecting “Allpoints” button 4614. Meter distribution tree 4604 includes spaces tree4616, which allows the user to select a particular space. Selecting aspace via meter distribution tree 4604 may cause a selected point to beassociated with the space and may cause system details panel 4606 to bedisplayed.

System details panel 4606 allows a user to define a new meter. Forexample, the user can specify the type of system (e.g., meter, airhandling unit, VAV box, chiller, boiler, heat exchanger, pump, fan,etc.). Selecting “meter” from the system dropdown menu 4618 identifiesthe new item as a meter. The user can specify the nature of the metervia the meter nature dropdown menu 4620. For example, the user canspecify whether the meter measures electricity, gas, steam, water,sewer, propane, fuel, diesel, coal, BTU, or any other type of commoditywhich can be measured by a meter. The user can specify the meter type(e.g., online, virtual, baseline, calculated point, fault, etc.) via themeter type dropdown menu 4622. Finally the user can enter the meter namein the meter name box 4624. The information can be saved by clickingsave button 4626.

As shown in FIGS. 47-49, the selected space 4702 in meter distributiontree 4604 may be updated to include the type of commodity 4704 measuredby the meter 4706 (e.g., “Electricity”) and the name of the meter 4706which measures the commodity (e.g., “Electric Meter”). This may occurautomatically in response to the user clicking save button 4626. Points4802-4804 can be added to the user-specified meter 4706 by dragging anddropping points 4802-4804 from point tree 4602 onto meter 4706 in meterdistribution tree 4604 (shown in FIG. 48). Existing meters 4902 whichmeasure a particular commodity can be added to meter distribution tree4604 by dragging and dropping meters 4902 from points tree 4602 onto thecommodity (e.g., electricity 4904) in meter distribution tree 4604(shown in FIG. 49).

Referring now to FIGS. 50-51, overview dashboard 1900 may beautomatically updated to display data from the new spaces added andconfigured via setup interface 3600. For example, portfolio 1910 isshown to include the newly added facility 5002 “IEC Mumbai” innavigation pane 1902. The energy-related data associated with newfacility 5002 is also shown in EUI widget 2402 and energy consumptiontracker widget 2404 (shown in FIG. 50).

As shown in FIG. 51, any meters 5102-5104 associated with the new spacemay also be displayed in navigation pane 1902. Data provided by meters5102-5104 may be shown in energy consumption widget 2702 and energydemand widget 2704, which may be the same or similar as previouslydescribed. For example, widgets 2702-2704 shown in FIG. 51 may beconfigured to display meter data for a current time period 5106 and aprevious time period 5108. Current time period 5106 may be populatedusing real-time data received from meters 5102-5104. Previous timeperiod 5108 may be unpopulated until historical data is retrieved formeters 5102-5104 (as described with reference to FIG. 45). Afterhistorical data is retrieved, dashboard 1900 may be automaticallyupdated to display the historical data along with the current data inenergy consumption widget 2702 and energy demand widget 2704.

Energy Analytics

Referring now to FIG. 52, a block diagram illustrating analytics service524 in greater detail is shown, according to an exemplary embodiment.Analytics service 524 can be implemented as one of data platformservices 520 in BMS 500 (as described with reference to FIGS. 5-6), as aseparate analytics system in BMS 500, or as a remote (e.g., cloud-based)analytics system outside BMS 500. Analytics service 524 can receiveinput from components of BMS 500 (e.g., local storage 514, hostedstorage 516, meters 5204, etc.) as well as external systems and devices(e.g., weather service 5202). For example, analytics service 524 can usethe timeseries data from local storage 514 and/or hosted storage 516 incombination with weather data from weather service 5202 and meter datafrom meters 5204 to perform various energy analytics. Analytics service524 can provide results of the energy analytics as outputs toapplications 530, client devices 448, and remote systems andapplications 444. In some embodiments, analytics service 524 stores theresults of the analytics as timeseries data in local storage 514 and/orhosted storage 516.

Analytics service 524 is shown to include a weather normalization module5208. Weather normalization module 5208 can be configured normalize theenergy consumption data for a facility, building, or other space toremove the effects of weather. By normalizing the energy consumptiondata in this way, changes in the normalized energy consumption data canbe attributed factors other than weather (e.g., occupancy load,equipment efficiency, etc.). Weather normalization module 5208 candetermine an expected energy usage after removing the effects of weatherand can generate normalized energy usage statistics including, forexample, a difference between actual and expected energy usage, apercentage change, a coefficient of variation of root mean square error(CVRME), and other energy usage statistics based on the normalizedenergy usage data.

In some embodiments, weather normalization module 5208 receiveshistorical meter data. Historical meter data can include historicalvalues for measurable amounts of resource consumption including, forexample, electric consumption (kWh), water consumption (gallons), andnatural gas consumption (mmBTU). The historical meter data can bereceived as timeseries data from local storage 514 or hosted storage516, collected from meters 5204 over time, or received from an energyutility (e.g., as part of an energy bill). In some embodiments, thehistorical meter data includes one year or more of historical meterdata. However, the historical meter data may cover other time periods invarious other embodiments (e.g., six months, three months, one month,etc.). Weather normalization module 5208 can also receive current meterdata from meters 5204.

In some embodiments, weather normalization module 5208 receives weatherdata from weather service 5202. Weather data can include outside airtemperature measurements, humidity measurements, rainfall amounts, windspeeds, or other data indicative of weather conditions. In someembodiments, the weather data includes cooling degree day (CDD) data andheating degree day (HDD) data. CDD data and HDD data can be provided astimeseries data having a CDD value and/or HDD value for each element ofthe timeseries. In some embodiments, CDD and HDD are defined as:

CDD_(i)=max(0,T _(TOA,i) −T _(BalancePoint))

HDD_(i)=max(0,T _(BalancePoint) −T _(OA,i))

where T_(OA,i) is the outside air temperature at time step i andT_(BalancePoint) is a temperature parameter (e.g., 60 degrees F.).T_(BalancePoint) can be set/adjusted by a user, or can be automaticallyset/adjusted based on the temperature setpoint for the building or spacebeing controlled.

In some embodiments, T_(OA,i) is the average daily outside airtemperature. T_(OA,i) can be calculated as an average of the hourlytemperature values or as an average of the high and low temperaturevalues for the day. For example, T_(OA,i) can be calculated using eitherof the following equations:

$T_{{OA},i} = \frac{\sum\limits_{j = 1}^{24}\; T_{{OA},{ij}}}{24}$$T_{{OA},i} = \frac{T_{{high},i} - T_{{low},i}}{2}$

where T_(OA,ij) is the hourly outside air temperature at hour j of dayi, T_(high,i) is the highest temperature value of day i, and T_(low,i)is the lowest temperature value of day i. In some embodiments, CDD andHDD are provided as timeseries data by weather service 5202. In otherembodiments, weather service 5202 provides T_(OA) as timeseries data andweather normalization module 5208 calculates the CDD timeseries and HDDtimeseries based on the timeseries values of T_(OA).

In some embodiments, weather normalization module 5208 uses the weatherdata and meter data to predict an amount of energy usage for thebuilding or space after removing the effects of weather. Weathernormalization module 5208 can compare the expected amount of energyusage to the actual amount of energy usage (defined by the meter data)to determine a difference or delta between the expected normalizedenergy usage and the actual energy usage, as shown in the followingequation:

ΔUsage_(i)=Usage_(expected,i)−Usage_(actual,i)

where Usage_(expected,i) is the expected amount of energy usage afterremoving the effects of weather and Usage_(actual,i) is the actualamount of energy usage measured by meters 5204. In some embodiments,weather normalization module 5208 calculates a percentage change betweenthe actual usage and the expected usage, as shown in the followingequation:

${{Percentage}\mspace{14mu} {Change}} = {100*\frac{{Usage}_{{actual},i} - {Usage}_{{expected},i}}{{Usage}_{{expected},i}}}$

where each of Usage_(actual,i) and Usage_(expected,i) is a timeseriesvalue at time step i.

In some embodiments, weather normalization module 5208 calculates acoefficient of variation of root mean square error (CVRME) based on theactual and expected energy usage values. CVRME is a measure ofperformance between the actual energy usage values and the expectedenergy usage values. Given a timeseries of n values for each timeseries,weather normalization module 5208 can calculate CVRME as follows:

${CVRME} = \frac{\sqrt{\frac{\sum\limits_{i = 1}^{n}\; \left( {{\hat{Y}}_{i} - Y_{i}} \right)^{2}}{n}}}{\overset{\_}{Y}}$

where Ŷ_(i) is the predicted energy usage at time step i (i.e.,Usage_(expected,i)), Y_(i) is the actual energy usage at time step i(i.e., Usage_(actual,i)), and Y is the mean of the timeseries Y.

Referring now to FIG. 53, a flowchart of a process 5300 for normalizingenergy consumption data to remove the effects of weather is shown,according to an exemplary embodiment. Process 5300 can be performed byweather normalization module 5208 normalize the energy consumption datafor a facility, building, or other space to remove the effects ofweather on the energy consumption values.

Process 5300 is shown to include calculating normalized CDD, HDD, andenergy consumption for each time interval in a baseline period (step5302). In some embodiments, the baseline period is a previous year andeach time interval in the baseline period is a month in the previousyear. However, it is contemplated that the baseline period and timeintervals can have any duration in various other embodiments. In someembodiments, the normalized CDD, HDD, and energy consumption values areaverage CDD, HDD, and energy consumption values for each time interval.For example, the normalized CDD value for a given month can becalculated by dividing the total CDD for the month (i.e., the sum of theCDD values for each day in the month) by the number of days in themonth, as shown in the following equation:

$\overset{\_}{CDD} = \frac{\Sigma_{month}{CDD}}{\# \mspace{14mu} {days}\mspace{14mu} {in}\mspace{14mu} {month}}$

where CDD is the normalized CDD value (CDD/day) and CDD is a daily CDDvalue for a given day in the month.

Similarly, the normalized HDD value for a given month can be calculatedby dividing the total HDD for the month (i.e., the sum of the HDD valuesfor each day in the month) by the number of days in the month, as shownin the following equation:

$\overset{\_}{HDD} = \frac{\Sigma_{month}{HDD}}{\# \mspace{14mu} {days}\mspace{14mu} {in}\mspace{14mu} {month}}$

where HDD is the normalized HDD value (HDD/day) and HDD is a daily HDDvalue for a given day in the month.

The normalized energy consumption for a given month can be calculated bydividing the total energy consumption for the month by the number ofdays in the month, as shown in the following equation:

$\overset{\_}{Usage} = \frac{\Sigma_{month}{Usage}}{\# \mspace{14mu} {days}\mspace{14mu} {in}\mspace{14mu} {month}}$

where Usage is the normalized energy consumption value (kWh/day) andUsage is a daily energy consumption value for a given day in the month.Each of the normalized values CDD, HDD, and Usage can be calculated foreach time interval (e.g., each month) in the baseline period (e.g.,previous year) to generate a timeseries of values (e.g., monthly values)for the baseline period.

Still referring to FIG. 53, process 5300 is shown to include generatingan energy consumption model using the baseline CDD, HDD, and energyconsumption values (step 5304). In some embodiments, the energyconsumption model has the form:

Usage=b ₀ +b ₁*CDD+b ₂*HDD

where the values of b₀, b₁, and b₂ are determined by applying aregression (e.g., weighted least squares) to the timeseries of valuesfor CDD, HDD, and Usage. An example of an energy consumption model whichcan be generated in step 5304 is shown in FIG. 54.

Referring to FIG. 54, a graph 5400 of timeseries values is shown,according to an exemplary embodiment. Graph 5400 plots the timeseries ofnormalized CDD values CDD (x-axis) against the corresponding energyconsumption values Usage (y-axis). The normalized HDD values are omittedfor simplicity. Each point 5402 in graph 5400 represents a pairing of anormalized CDD value and the corresponding normalized energy consumptionvalue. Line 5404 represents the relationship between the variables CDDand Usage. The following equation can be used to represent thesimplified model shown in FIG. 54:

Usage=b ₀ +b ₁*CDD

where the values of b₀, and b₁ are determined by applying a regression(e.g., weighted least squares) to the timeseries of values for CDD andUsage. For example, the regression may generate values of b₀=20.1kWh/day and b₁=200.1 CDD/day, which results in the simplified model:

Usage=20.1+200.1*CDD

Referring again to FIG. 53, process 5300 is shown to include estimatingnormalized energy consumption for a current time period by applyingcurrent CDD and HDD values to the energy consumption model (step 5306).In some embodiments, the current time period is a current month. Thecurrent CDD and HDD values can be received from weather service 5202 orcalculated by weather normalization module 5208 based on current weatherconditions, as described with reference to FIG. 52. In some embodiments,the current CDD and HDD values are normalized CDD and HDD values for thecurrent month, which can be calculated as described with reference tostep 5302.

Step 5306 can include using the current CDD and HDD values as inputs tothe energy consumption model and solving for the energy consumptionvalue. For example, if the current CDD value is

${\overset{\_}{CDD} = {50\frac{CDD}{day}}},$

the simplified model can be solved as follows:

$\overset{\_}{Usage} = {20.1 + {200.1*\overset{\_}{CDD}}}$$\overset{\_}{Usage} = {20.1 + {200.1*50}}$$\overset{\_}{Usage} = {10,025.1\frac{kWh}{day}}$

Process 5300 is shown to include multiplying the normalized energyconsumption estimate by the duration of the current time period todetermine the total expected energy consumption during the current timeperiod (step 5308). For example, if the current time period has aduration of 31 days, the normalized energy consumption Usage can bemultiplied by 31 to determine the expected energy consumption for thecurrent month. The following equations show an example of thecalculation performed in step 5308 using the normalized energyconsumption value calculated in step 5306:

${Usage}_{expected} = {\overset{\_}{Usage}*{duration}}$${Usage}_{expected} = {10,025.1\frac{kWh}{day}*31\mspace{14mu} {days}}$Usage_(expected) = 310778.1  kWh

Process 5300 is shown to include generating energy consumptionstatistics based on expected and actual energy consumption during thecurrent time period (step 5310). The expected energy consumption may bethe value Usage_(expected) calculated in step 5308. The actual energyconsumption may be the value Usage_(current), which can be measured bymeters 5204, received from local storage 514 or hosted storage 516,obtained from a utility (e.g., a utility bill), or otherwise observedduring the current time period.

The energy consumption statistics may include, for example, a differenceor delta between the expected normalized energy usage Usage_(expected)and the actual energy usage Usage_(current) (e.g., ΔUsage), a percentagechange between the actual usage Usage_(current) and the expected usageUsage_(expected,) a CVRME based on the actual and expected energy usagevalues, or other statistics derived from the actual energy usageUsage_(current) and the expected energy usage Usage_(expected.) Theseand other energy consumption statistics can be calculated by weathernormalization module 5208 as previously described. Process 5300 can berepeated periodically (e.g., monthly) to calculate energy consumptionstatistics for each time period (e.g., each month) as that time periodbecomes the current time period.

In some embodiments, the number of data points used to generate theenergy consumption model is at least twice the number of parameters inthe model. For example, for an energy consumption model with threeparameters b₀, b₁, and b₂ a minimum of six data points (e.g., six monthsof historical data) may be used to train the model. In some embodiments,a full year of data is used to train the energy consumption model. Ifless than a full year of historical data is used, weather normalizationmodule 5208 may flag the resulting energy consumption model aspotentially unreliable. Once a full year of data has been collected,weather normalization module 5208 may remove the flag to indicate thatthe energy consumption model is no longer potentially unreliable.

In some embodiments, weather normalization module 5208 uses up to threeyears of historical data to train the energy consumption model. Using upto three years of data can minimize the impact of an anomalous year butreduces the likelihood of the baseline model changing(non-stationarity). In some embodiments, weather normalization module5208 recalculates the energy consumption model on the first of eachmonth with all available data up to but not exceeding three years. Inaddition to automatically updating the energy consumption modelperiodically, a user-defined trigger can be used to force arecalculation of the baseline model. The user-defined trigger can be amanual trigger (e.g., a user selecting an option to update the model)which allows the model to be updated in cases where a known change hasoccurred in the building (e.g., new zone added, hours of operationextended, etc.).

In some embodiments, historical data collected before the user-definedtrigger is excluded when retraining the energy consumption model inresponse to the user-defined trigger. Alternatively, the user-definedtrigger can require the user to specify a date, which is used as athreshold before which all historical data is excluded when retrainingthe model. If a user does not specify a date, weather normalizationmodule 5208 may use all available data by default. If the user specifiesthe current date, weather normalization module 5208 may wait for apredetermined amount of time (e.g., six months) before retraining theenergy consumption model to ensure that sufficient data is collected.The predetermined amount of time may be the minimum amount of timerequired to collect the minimum number of data points needed to ensurereliability of the model (e.g., twice the number of parameters in themodel). During the waiting period, weather normalization module 5208 maydisplay a message indicating that estimates cannot be generated untilthe end of the waiting period.

Referring again to FIG. 52, analytics service 524 is shown to include anenergy benchmarking module 5210. Energy benchmarking module 5210 can beconfigured compare the energy consumption of a given building orfacility to benchmark energy consumption values for buildings of asimilar type. Energy benchmarking module 5210 may also compare theenergy consumption of a given building or facility to baseline typicalbuildings of similar type in different geographical locations.

In some embodiments, energy benchmarking module 5210 receives historicalmeter data. Historical meter data can include historical values formeasurable amounts of resource consumption including, for example,electric consumption (kWh), water consumption (gallons), and natural gasconsumption (mmBTU). The historical meter data can be received astimeseries data from local storage 514 or hosted storage 516, collectedfrom meters 5204 over time, or received from an energy utility (e.g., aspart of an energy bill). In some embodiments, the historical meter dataincludes one year or more of historical meter data. However, thehistorical meter data may cover other time periods in various otherembodiments (e.g., six months, three months, one month, etc.). Energybenchmarking module 5210 can also receive current meter data from meters5204.

Energy benchmarking module 5210 may receive building parameters fromparameters database 5206. Building parameters may include variouscharacteristics or attributes of the building such as building area(e.g., square feet), building type (e.g., one of a plurality ofenumerated types), building location, and building benchmarks for theapplicable building type and/or location. Building benchmarks caninclude benchmark energy consumption values for the building. Thebenchmarks can be ASHRAE benchmarks for buildings in the United Statesor other local standards for buildings in different countries. In someembodiments, the benchmarks specify an energy use intensity (EUI) valueand/or energy density value for the building. EUI is a normalized metricwhich quantifies the energy consumption of a building per unit area overa given time period

$\left( {{e.g.},\frac{kWh}{{ft}^{2}*{year}}} \right).$

Similarly, energy density is a normalized metric which quantifies thechange in energy consumption of the building per unit area over a giventime period

$\left( {{e.g.},\frac{\Delta \; {kWh}}{{ft}^{2}*{hour}}} \right).$

EUIs and energy densities can also be calculated for other commoditiessuch as water consumption, natural gas consumption, etc.

Energy benchmarking module 5210 can use the historical meter data andbuilding parameters to calculate EUI values and/or energy density valuesfor the building. In some embodiments, energy benchmarking module 5210calculates EUI values and/or energy density values for one-year timeperiods. This may allow the EUI values and/or energy density values tobe directly compared to ASHRAE standards, which are defined by year.However, it is contemplated that EUI and/or energy density can becalculated for any time period (e.g., monthly, weekly, daily, hourly,etc.) to allow for comparison with other standards or benchmarks thatuse different time periods.

In some embodiments, energy benchmarking module 5210 collects energyconsumption data, energy density values, and/or EUI values for allbuildings in a portfolio and separates the buildings by type ofbuilding. Energy benchmarking module 5210 can plot all buildings of asingle type on one plot along with benchmarks for that building type atdifferent geographical locations (e.g., different cities). An example ofa plot 5500 which can be generated by energy benchmarking module 5210 isshown in FIG. 55. Plot 5500 shows all of the buildings in the customer'sportfolio that have the building type “Office Building.” These buildinginclude Building A, Building B, Building C, and Building D. Plot 5500shows the EUI values for each of Buildings A, B, C, and D. Plot 5500also shows typical or benchmark EUI values for typical buildings of thesame type (i.e., office buildings) in various geographic locations(e.g., Houston, Miami, Chicago, San Francisco, Kansas City, Fairbanks,Phoenix). The visualization shown in plot 5500 allows the customer tosee how their buildings compare to similar buildings in their city orother cities with similar weather patterns. Although only EUI is shown,it should be understood that plot 5500 can include energy density inaddition to EUI or in place of EUI in various embodiments.

Referring again to FIG. 52, analytics service 524 is shown to include abaseline comparison module 5212. Baseline comparison module 5212 can beconfigured to compare various timeseries against a baseline. Forexample, baseline comparison module 5212 can compare energy consumption,energy demand, EUI, energy density, or other timeseries whichcharacterize the energy performance of a building. Baseline comparisonmodule 5212 can compare timeseries at any level of granularity. Forexample, baseline comparison module 5212 can compare timeseries for anentire facility, a particular building, space, room, zone, meter (bothphysical meters and virtual meters), or any other level at whichtimeseries data can be collected, stored, or aggregated.

Baseline comparison module 5212 can compare timeseries data for anycommodity (e.g., electricity, natural gas, water, etc.) and at any timeduration (e.g., yearly, monthly, daily, hourly, etc.). In someembodiments, energy benchmarking module 5210 receives historical meterdata. Historical meter data can include historical values for measurableamounts of resource consumption including, for example, electricconsumption (kWh), water consumption (gallons), and natural gasconsumption (mmBTU). The historical meter data can be received astimeseries data from local storage 514 or hosted storage 516, collectedfrom meters 5204 over time, or received from an energy utility (e.g., aspart of an energy bill). In some embodiments, baseline comparison module5212 receives the EUI values and/or energy density values generated byenergy benchmarking module 5210, the energy usage statistics generatedby weather normalization module 5208, or other timeseries whichcharacterize the energy performance of a building or other space.Different EUI calculations and/or energy density calculations can beused to generate the EUI values and/or energy density values fordifferent time periods, as described with reference to energybenchmarking module 5210.

Baseline comparison module 5212 can compare timeseries against variousbaselines. The baselines may be threshold values which can be generatedin any of a variety of ways. For example, some baselines may be definedor set by a user. Some baselines can be calculated from historical data(e.g., average consumption, average demand, average EUI, average energydensity, etc.) and other building parameters. Some baselines can be setby standards such as ASHRAE 90.1 (e.g., for building-level standards).Baseline comparison module 5212 may receive building parameters fromparameters database 5206. Building parameters may include variouscharacteristics or attributes of the building such as building area(e.g., square feet), building type (e.g., one of a plurality ofenumerated types), building location, etc. Baseline comparison module5212 can use the building parameters to identify appropriate benchmarksagainst which the timeseries can be compared.

Baseline comparison module 5212 can output the baselines as well asresults of the baseline comparisons. The results can include indicationsof whether the samples of the timeseries are above or below thebaseline, fault triggers and time stamps, or other results which can bederived from the baseline comparison (e.g., compliance or non-compliancewith a standard, fault indications, etc.). For example, baselinecomparison module 5212 may apply fault detection rules which definefaults relative to baseline. In some embodiments, a fault is defined asa predetermined number of samples above a baseline or below a baseline.Baseline comparison module 5212 can compare each sample of a timeseriesto a baseline to determine, for each sample, whether the sample is aboveor below the baseline. If a threshold number of samples fulfil thecriteria of a fault detection rule (e.g., three consecutive samplesabove baseline, five of ten consecutive samples above baseline, etc.),baseline comparison module 5212 may generate a fault indication. Thefault indications can be stored as timeseries data in local storage 514or hosted storage 516 or provided to applications 530, client devices448, and/or remote systems and applications 444.

In some embodiments, baseline comparison module 5212 generates plots orgraphs which indicate the results of the baseline comparisons. Anexample of a graph 5600 which can be generated by baseline comparisonmodule 5212 is shown in FIG. 56. Graph 5600 plots the values of abuilding energy consumption timeseries 5602 relative to a baseline 5604.For each sample of timeseries 5602, baseline comparison module 5212 cancompare the value of the sample to baseline 5604. Any samples thatexceed baseline 5604 (i.e., samples, 5606), can be automaticallyhighlighted, colored, or otherwise marked by baseline comparison module5212 in graph 5600. This allows a user to readily identify anddistinguish the samples 5606 that exceed baseline 5604.

Referring again to FIG. 52, analytics service 524 is shown to include anight/day comparison module 5214. Night/day comparison module 5214 canbe configured to compare night building energy loads against daybuilding energy loads. The night/day comparison can be performed forenergy consumption, energy demand, EUI, energy density, or othertimeseries which characterize the energy performance of a building. Insome embodiments, night/day comparison module 5214 calculates a ratio ofthe minimum night load to the peak day load and compares the calculatedratio to a threshold (e.g., 0.5). If the ratio deviates from a thresholdby a predetermined amount (e.g., greater than 1.2 times the thresholdratio), night/day comparison module 5214 can generate a fault indicationwhich indicates a high nightly load.

In some embodiments, night/day comparison module 5214 receiveshistorical meter data. Historical meter data can include historicalvalues for measurable amounts of resource consumption including, forexample, electric consumption (kWh), water consumption (gallons), andnatural gas consumption (mmBTU). The historical meter data can bereceived as timeseries data from local storage 514 or hosted storage516, collected from meters 5204 over time, or received from an energyutility (e.g., as part of an energy bill). In some embodiments, thehistorical meter data includes one year or more of historical meterdata. However, the historical meter data may cover other time periods invarious other embodiments (e.g., six months, three months, one month,etc.). Night/day comparison module 5214 can also receive current meterdata from meters 5204.

In some embodiments, night/day comparison module 5214 receivestimeseries data from local storage 514 and/or hosted storage 516. Thetimeseries data can include one or more timeseries of energyconsumption, energy demand, EUI, energy density, or other timeserieswhich characterize the energy performance of a building. In someembodiments, night/day comparison module 5214 receives a buildingschedule as an input. Night/day comparison module 5214 can use thebuilding schedule to separate the timeseries into night portions (e.g.,samples of the timeseries with timestamps at night) and day portions(e.g., samples of the timeseries with timestamps during the day). Insome embodiments, the building schedule is an occupancy schedule. Inother embodiments, the building schedule defines the sunrise time andsunset time at the geographic location of the building. Night/daycomparison module 5214 can receive the building schedule as an input orcan automatically generate the building schedule. For example, night/daycomparison module 5214 can automatically determine the sunrise times andsunset times for a building based on the date and the geographiclocation of the building (e.g., zip code, latitude and longitude, etc.).

Night/day comparison module 5214 can use the timeseries data tocalculate a load ratio Q_(ratio) for the one or more timeseries. In someembodiments, the load ratio Q_(ratio) is a ratio of the minimum loadduring night hours (e.g., a minimum of the timeseries samples designatedas nighttime samples) to the maximum load during day hours (e.g., amaximum of the timeseries samples designated as daytime samples). Forexample, night/day comparison module 5214 can calculate the load ratiofor a given timeseries using the following equation:

$Q_{ratio} = \frac{Q_{\min}}{Q_{\max}}$

where Q_(min) is the minimum load during night hours and Q_(max) is themaximum load during day hours. Night/day comparison module 5214 cancalculate the load ratio Q_(ratio) for each timeseries using the samplesof the timeseries. Night/day comparison module 5214 can generate a valueof Q_(ratio) for each day of each timeseries. In some embodiments,night/day comparison module 5214 stores the daily values of Q_(ratio) asa new timeseries in local storage 514 and/or hosted storage 516. Eachelement of the new timeseries may correspond to a particular day and mayinclude the calculated value of Q_(ratio) for that day.

Night/day comparison module 5214 can receive a threshold parameter fromparameters database 5206. The threshold parameter may be a thresholdratio between night load and day load. In some embodiments, thethreshold ratio has a value of approximately T=0.5. However, it iscontemplated that the threshold ratio can have any value in variousother embodiments. The value of the threshold ratio can bedefined/updated by a user, automatically calculated based on a historyof previous night loads and day loads, or otherwise determined bynight/day comparison module 5214.

Night/day comparison module 5214 can compare the calculated load ratioQ_(ratio) to the threshold value T (or to some function of the thresholdT). In some embodiments, night/day comparison module 5214 determineswhether the calculated load ratio Q_(ratio) exceeds the threshold T by apredetermined amount (e.g., 20%). For example, night/day comparisonmodule 5214 can evaluate the following inequality to determine whetherthe calculated load ratio Q_(ratio) exceeds the threshold T by apredetermined amount θ:

Q _(ratio) ≥θ*T

where the parameter θ is a indicates an amount or percentage by whichthe ratio Q_(ratio) must exceed the threshold T to qualify as a fault.For example, a value of θ=1.2 indicates that the ratio Q_(ratio)qualifies as a fault if Q_(ratio) exceeds the threshold T by 20% ormore.

Night/day comparison module 5214 can output the load ratio timeseries aswell as the results of the threshold comparisons. The results caninclude indications of whether the calculated load ratios Q_(ratio) areabove or below the threshold value T (or a function of the thresholdvalue T), fault triggers and time stamps, or other results which can bederived from the threshold comparison (e.g., compliance ornon-compliance with a standard, fault indications, etc.). For example,night/day comparison module 5214 may apply fault detection rules whichdefine faults relative to threshold T. In some embodiments, a fault isdefined as a predetermined number of samples of Q_(ratio) that satisfythe inequality Q_(ratio)≥θ*T. The fault indications can be stored astimeseries data in local storage 514 or hosted storage 516 or providedto applications 530, client devices 448, and/or remote systems andapplications 444.

In some embodiments, night/day comparison module 5214 generates plots orgraphs which indicate the results of the threshold comparisons. Anexample of a graph 5700 which can be generated by night/day comparisonmodule 5214 is shown in FIG. 57. Graph 5700 plots a timeseries 5702 ofbuilding energy consumption for a three day period. For each day (e.g.,Day 1, Day 2, Day 3), night/day comparison module 5214 may identify allof the samples of timeseries 5702 with timestamps during that day.Night/day comparison module 5214 may also classify each sample oftimeseries 5702 as either a night sample or a day sample based on thetime at which the sample was recorded. Samples obtained during nighthours may be classified as night samples, whereas samples obtainedduring day hours may be classified as day samples.

For each day, night/day comparison module 5214 may identify the minimumof the night samples for that day (i.e., Q_(min)) and the maximum of theday samples for that day (i.e., Q_(max)). Night/day comparison module5214 can calculate a ratio Q_(ratio) for each day using the followingequation:

$Q_{ratio} = \frac{Q_{\min}}{Q_{\max}}$

and can compare the calculated ratio to a threshold T (or a function ofthreshold T) as shown in the following inequality:

Q _(ratio) ≥θ*T

If the ratio Q_(ratio) for a given day satisfies the inequality,night/day comparison module 5214 can automatically highlight, color, orotherwise mark the samples for that day in graph 5700. For example,samples 5704 for Day 2 may be colored red to indicate that the ratioQ_(ratio) for Day 2 exceeds the threshold T by the amount θ (e.g., 20%).

Referring again to FIG. 52, analytics service 524 is shown to include aweekend/weekday comparison module 5216. Weekend/weekday comparisonmodule 5216 can be configured to compare weekend building energy loadsagainst weekday building energy loads. The weekend/weekday comparisoncan be performed for energy consumption, energy demand, EUI, energydensity, or other timeseries which characterize the energy performanceof a building. In some embodiments, weekend/weekday comparison module5216 calculates a ratio of the weekend load to the to the weekday loadand compares the calculated ratio to a threshold (e.g., 0.5). If theratio deviates from a threshold by a predetermined amount (e.g., greaterthan 1.2 times the threshold ratio), weekend/weekday comparison module5216 can generate a fault indication which indicates a high weekendload.

In some embodiments, weekend/weekday comparison module 5216 receiveshistorical meter data. Historical meter data can include historicalvalues for measurable amounts of resource consumption including, forexample, electric consumption (kWh), water consumption (gallons), andnatural gas consumption (mmBTU). The historical meter data can bereceived as timeseries data from local storage 514 or hosted storage516, collected from meters 5204 over time, or received from an energyutility (e.g., as part of an energy bill). In some embodiments, thehistorical meter data includes one year or more of historical meterdata. However, the historical meter data may cover other time periods invarious other embodiments (e.g., six months, three months, one month,etc.). Weekend/weekday comparison module 5216 can also receive currentmeter data from meters 5204. In some embodiments, weekend/weekdaycomparison module 5216 receives timeseries data from local storage 514and/or hosted storage 516. The timeseries data can include one or moretimeseries of energy consumption, energy demand, EUI, energy density, orother timeseries which characterize the energy performance of abuilding.

Weekend/weekday comparison module 5216 can use the timeseries data tocalculate a load ratio Q_(ratio) for the one or more timeseries. In someembodiments, the load ratio Q_(ratio) is a ratio of the average loadduring the weekend (e.g., an average of the timeseries samplesdesignated as weekend samples) to the average load during the weekdays(e.g., an average of the timeseries samples designated as weekdaysamples). For example, weekend/weekday comparison module 5216 cancalculate the load ratio for a given timeseries using the followingequation:

$Q_{ratio} = \frac{Q_{weekend}}{Q_{weekday}}$

where Q_(weekend) is the average load during the weekend and Q_(weekday)is the average load during the weekdays. Weekend/weekday comparisonmodule 5216 can calculate the load Q_(ratio) for each timeseries usingthe samples of the timeseries. Weekend/weekday comparison module 5216can generate a value of Q_(ratio) for each week of each timeseries. Insome embodiments, weekend/weekday comparison module 5216 stores thedaily values of Q_(ratio) as a new timeseries in local storage 514and/or hosted storage 516. Each element of the new timeseries maycorrespond to a particular week and may include the calculated value ofQ_(ratio) for that week.

Weekend/weekday comparison module 5216 can receive a threshold parameterfrom parameters database 5206. The threshold parameter may be athreshold ratio between weekend load and weekday load. In someembodiments, the threshold ratio has a value of approximately T=0.5.However, it is contemplated that the threshold ratio can have any valuein various other embodiments. The value of the threshold ratio can bedefined/updated by a user, automatically calculated based on a historyof previous weekend loads and weekday loads, or otherwise determined byweekend/weekday comparison module 5216.

Weekend/weekday comparison module 5216 can compare the calculated loadratio Q_(ratio) to the threshold value T (or to some function of thethreshold T). In some embodiments, weekend/weekday comparison module5216 determines whether the calculated load ratio Q_(ratio) exceeds thethreshold T by a predetermined amount (e.g., 20%). For example,weekend/weekday comparison module 5216 can evaluate the followinginequality to determine whether the calculated load ratio Q_(ratio)exceeds the threshold T by a predetermined amount θ:

Q _(ratio) ≥θ*T

where the parameter θ is a indicates an amount or percentage by whichthe ratio Q_(ratio) must exceed the threshold T to qualify as a fault.For example, a value of θ=1.2 indicates that the ratio Q_(ratio)qualifies as a fault if Q_(ratio) exceeds the threshold T by 20% ormore.

Weekend/weekday comparison module 5216 can output the load ratiotimeseries as well as the results of the threshold comparisons. Theresults can include indications of whether the calculated load ratiosQ_(ratio) are above or below the threshold value T (or a function of thethreshold value T), fault triggers and time stamps, or other resultswhich can be derived from the threshold comparison (e.g., compliance ornon-compliance with a standard, fault indications, etc.). For example,weekend/weekday comparison module 5216 may apply fault detection ruleswhich define faults relative to threshold T. In some embodiments, afault is defined as a predetermined number of samples of Q_(ratio) thatsatisfy the inequality Q_(ratio)≥θ*T. The fault indications can bestored as timeseries data in local storage 514 or hosted storage 516 orprovided to applications 530, client devices 448, and/or remote systemsand applications 444.

In some embodiments, weekend/weekday comparison module 5216 generatesplots or graphs which indicate the results of the threshold comparisons.An example of a graph 5800 which can be generated by weekend/weekdaycomparison module 5216 is shown in FIG. 58. Graph 5800 plots atimeseries 5802 of building energy consumption for a one-week period.For each week, weekend/weekday comparison module 5216 may identify allof the samples of timeseries 5802 with timestamps during that week.Weekend/weekday comparison module 5216 may also classify each sample oftimeseries 5802 as either a weekend sample or a weekday sample based onthe time at which the sample was recorded. Samples obtained duringweekend days (i.e., Saturday and Sunday) may be classified as weekendsamples, whereas samples obtained during weekdays (i.e., Monday-Friday)may be classified as weekday samples.

For each week, weekend/weekday comparison module 5216 may calculate theaverage of the weekday samples for that week (i.e., Q_(weekday)) and theaverage of the weekend samples for that week (i.e., Q_(weekend)).Weekend/weekday comparison module 5216 can calculate a ratio Q_(ratio)for each week using the following equation:

$Q_{ratio} = \frac{Q_{weekend}}{Q_{weekday}}$

and can compare the calculated ratio to a threshold T (or a function ofthreshold T) as shown in the following inequality:

Q _(ratio) ≥θ*T

If the ratio Q_(ratio) for a given day satisfies the inequality,weekend/weekday comparison module 5216 can automatically highlight,color, or otherwise mark the weekend samples for that week in graph5800. For example, samples 5804 for the weekend may be colored red toindicate that the ratio Q_(ratio) exceeds the threshold T by the amountθ (e.g., 20%).

Ad Hoc Dashboard

Referring now to FIGS. 59-87, several user interfaces which can begenerated by building management system 500 are shown, according to anexemplary embodiment. In some embodiments, user interfaces are generatedby energy management application 532, monitoring and reportingapplication 534, enterprise control application 536, or otherapplications 530 that consume the optimized timeseries data generated bydata platform services 520. For example, the user interfaces can begenerated by a building energy management system which includes aninstance of energy management application 532. One example of such abuilding energy management system is the METASYS® Energy ManagementSystem (MEMS) by Johnson Controls Inc. The building energy managementsystem can be implemented as part of building management system 500(e.g., one of applications 530) or as a cloud-based application (e.g.,one of remote systems and applications 444) in communication withbuilding management system 500 via communications network 446 (e.g., theInternet, a LAN, a cellular network, etc.).

In some embodiments, the user interfaces are components of an ad hocdashboard 5900. Ad hoc dashboard 5900 may be displayed when a userclicks ad hoc tab 5902 shown in FIG. 59. Ad hoc dashboard 5900 may becustomizable to allow the user to create and configure various types ofwidgets. The widgets can be configured to visually present timeseriesdata from local storage 514 or hosted storage 516, as well as othertypes of information. For example, ad hoc dashboard 5900 can becustomized to include charting widgets, data visualization widgets,display widgets, time and date widgets, weather information widgets, andvarious other types of widgets. Several examples of user interfaces forcreating and configuring widgets are described in detail below.

Creating Widgets

Referring now to FIGS. 60-61, a user interface 6000 for creating widgetsis shown, according to an exemplary embodiment. User interface 6000 maybe displayed as a popup when a user clicks the “Create Widgets” button5904 in ad hoc dashboard 5900. Interface 6000 may allow a user to entera widget name 6002 (“Widget 1”) and select a type of widget to create.In some embodiments, the user selects a widget type by selecting anoption presented via one of dropdown menus 6004-6012.

Selecting data visualization dropdown menu 6004 may display a list ofdata visualization widgets that can be created. In some embodiments, thedata visualization widgets include a heat map widget, a radial gaugewidget, a histogram widget, and a psychometric chart widget. Selectingcharting dropdown menu 6006 may display a list of charting widgets thatcan be created. In some embodiments, the charting widgets include a linechart widget, an area chart widget, a column chart widget, a bar chartwidget, a stacked chart widget, and a pie chart widget. Selecting timeand date dropdown menu 6008 may display a list of time and date widgetsthat can be created. In some embodiments, the time and date widgetsinclude a date display widget, a digital clock widget, and an analogclock widget. Selecting display dropdown menu 6010 may display a list ofdisplay widgets that can be created. In some embodiments, the displaywidgets include a data point widget, a data grid widget, a text boxwidget, and an image widget. Selecting weather dropdown menu 6012 maydisplay a list of weather widgets that can be created. In someembodiments, the weather widgets include a current weather informationwidget and a weather forecast widget.

After the user selects a widget via one of dropdown menus 6004-6012, theuser can click save button 6014 to create an empty widget of theselected type. An example of an empty widget 6102 which can be createdis shown in FIG. 61. Empty widget 6102 may include the widget name 6002and text 6104 indicating that no data is currently associated with emptywidget 6102. Empty widget 6102 can be associated with one or moretimeseries via widget configuration interface 6200.

Configuring Widgets

Referring now to FIGS. 62-63, a widget configuration interface 6200 isshown, according to an exemplary embodiment. Widget configurationinterface 6200 allows a user to associate an empty widget 6102 with oneor more timeseries or other types of data. For example, points frommeter tree 6204 can be dragged and dropped into empty widget 6102 toassociate the corresponding timeseries data with empty widget 6102.Although only a meter tree 6204 is shown, points can also be dragged anddropped from other types of trees such as an equipment tree. Upondragging and dropping a point into empty widget 6102, a chart of thetimeseries data associated with the selected point may begin populating.Empty widget 6102 can also be configured by selecting options button6202 and selecting “configure widget” from dropdown menu 6206. Dropdownmenu 6206 may also include options to delete or duplicate the selectedwidget. Duplicating a widget may include duplicating any points mappedto the widget as well as the widget's size and theme.

FIG. 63 illustrates a configure widget popup 6300 which may be displayedin response to a user selecting the configure widget option via dropdownmenu 6206. Configure widget popup 6300 is an example of a configurationinterface for a line chart widget. A line chart widget can be created byselecting the create widgets button 5904 in ad hoc dashboard 5900 andselecting line chart from the charting dropdown menu 6006. When a userdrags and drops any point from meter tree 6204, a line chart 6302 with asingle line may appear. Line chart 6302 may plot the timeseries samplesassociated with the selected point. The x-axis of line chart 6302 may beunits of time, whereas the y-axis of line chart 6302 may be the unit ofmeasure (UOM) of the selected point (e.g., kWh, kW, etc.). An axis label6304 with the UOM of the timeseries may be displayed along the y-axis.

If a second point with a different UOM is added to line chart 6302(e.g., by dragging and dropping the second point), line chart 6302 maybe automatically updated to include a second line plotting thetimeseries samples associated with the second point. The different UOMmay be displayed along the y-axis of line chart 6302 on the oppositeside (e.g., right side) from the UOM of the first point. An axis label6306 with the UOM of the second point may be displayed along the y-axisof line chart 6302. Any number of points can be added to line chart 6302regardless of whether the points have the same or different UOM.

In some embodiments, timeseries with different units of measure may bedisplayed in different colors in line chart 6302, whereas timeserieswith same units of measure may be displayed in the same color but asdifferent line types (e.g., solid lines, dashed lines, etc.). The axislabels 6304, 6304, and 6308 and numerical values along the y-axes ofline chart 6302 may have the same colors as the timeseries plotted inthe corresponding UOM. For example, axis label 6304 and thecorresponding numerical values along the left side of line chart 6302may be colored blue along with any lines which present data in that UOM(e.g., kWh, energy). Axis label 6306 and the corresponding numericalvalues along the right side of line chart 6302 may be colored greenalong with any lines which present data in that UOM (e.g., kW, power). Adifferent color may be used for each axis label and timeseries lineassociated with a different UOM.

In some embodiments, configure widget popup 6300 displays a list 6310 ofthe points mapped to the widget. Each point in points list 6310 mayidentify the point name and may allow the user to edit the names of themapped points, delete one or more of the mapped points, define thedecimal places for the values of the mapped points, and make other editsto the mapped points. Configure widget popup 6300 may also allow theuser to edit the widget title. A preview of the chart 6302 may bedisplayed in configure widget popup 6300 to allow the user to see thechanges in real time without closing configure widget popup 6300.

After a widget has been created, the user can click save button 6208 tosave the widget to ad hoc dashboard 5900. In some embodiments, adifferent ad hoc dashboard 5900 can be created for each level ofbuilding space, meter, and equipment. The widgets saved to a particularad hoc dashboard 5900 may be displayed when dashboard 5900 is refreshed(e.g., by refreshing a webpage in which ad hoc dashboard 5900 isdisplayed).

Data Aggregation Widget

Referring now to FIGS. 64-66, a data aggregation interface 6400 isshown, according to an exemplary embodiment. Data aggregation interface6400 allows a user to view the timeseries data associated with aparticular data point with different levels of granularity. For example,interface 6400 is shown to include an energy consumption widget 6402which displays the timeseries data associated with an energy consumptiontimeseries. Depending on the timeframe selected via timeframe selector6410, different data aggregation options 6406 may be displayed. Forexample, if one year is selected via timeframe selector 6410, dataaggregation options 6406 may include hourly, daily, weekly, and monthly(default). If six months is selected via timeframe selector 6410, dataaggregation options 6406 may include hourly, daily, weekly, and monthly(default). If three months is selected via timeframe selector 6410, dataaggregation options 6406 may include hourly, daily, weekly, and monthly(default). If one month is selected via timeframe selector 6410, dataaggregation options 6406 may include hourly, daily (default), andweekly. If one week is selected via timeframe selector 6410, dataaggregation options 6406 may include fifteen minutes, hourly, and daily(default). The default value may be highlighted.

Different data aggregation options 6406 may also be displayed for customtime periods. For example, if a custom time period of less than one weekis selected via timeframe selector 6410, data aggregation options 6406may include fifteen minutes, hourly, and daily. If a custom time periodbetween one week and one month is selected via timeframe selector 6410,data aggregation options 6406 may include fifteen minutes, hourly,daily, and weekly. If a custom time period of one month or longer isselected via timeframe selector 6410, data aggregation options 6406 mayinclude hourly, daily, weekly, and monthly.

In some embodiments, widget 6402 is automatically updated to display thetimeseries data associated with the selected aggregation option. Forexample, widget 6402 may display an hourly data rollup timeseries forthe point if the hourly data aggregation option is selected viaaggregation options 6406. However, widget 6402 may display a weekly datarollup timeseries for the same point if the weekly data aggregationoption is selected via aggregation options 6406. The x-axis of chart6408 may also be updated based on the selected data aggregation option.For example, widget 6402 may include a chart 6408 with an x-axis scaledto daily energy consumption values when the daily aggregation option isselected (shown in FIG. 64). However, widget 6402 may include a chart6602 with an x-axis scaled to weekly energy consumption values when theweekly aggregation option is selected (shown in FIG. 66). In someembodiments, widget 6402 includes a chart 6502 with an x-axis scaled toone data aggregation option (e.g., weekly), whereas the data presentedin chart 6502 may be from a more granular timeseries. For example, FIG.65 shows a chart 6502 with an x-axis scaled to weekly intervals anddisplaying hourly values of the energy consumption.

Heat Map Widget

Referring now to FIGS. 67-69, an interface 6700 for creating andconfiguring a heat map widget 6702 is shown, according to an exemplaryembodiment. Heat map widget 6702 can be created by selecting the createwidgets button 5904 in ad hoc dashboard 5900 and selecting heat map fromthe data visualization dropdown menu 6004. When a user drags and dropsany meter point from meter tree 6204, a heat map 6706 may appear. Insome embodiments, heat map 6706 is automatically overwritten if the userdrags and drops a second meter point from meter tree 6204. Interface6700 may display a message indicating that the point mapping has beenappended or changed when heat map 6706 is updated with a second meterpoint.

Heat map 6706 may present timeseries data as a plurality of cells 6710.Each of cells 6710 may correspond to one sample of the correspondingtimeseries. For example, heat map 6706 is shown displaying hourly valuesof an energy consumption timeseries. Each row of heat map 6706corresponds to a particular day, whereas each column of heat map 6706corresponds to an hour of the day. Cells 6710 located at theintersections of the rows and columns represent the hourly values of theenergy consumption timeseries. In some embodiments, the hourly energyconsumption values (or any other type of data presented via heat map6707) are indicated by the color or other attribute of cells 6710. Forexample, cells 6710 may have different colors that represent differentenergy consumption values. A key 6708 indicates the colors thatrepresent different numerical values of the energy consumptiontimeseries. As new samples of the timeseries are collected, new cells6710 may be added to heat map 6706. Hovering over any of cells 6710 maydisplay the timestamp of the sample associated with the cell, the pointname, and/or the numerical value of the sample associated with the cell.

In some embodiments, heat map widget 6702 includes an options button6712. Selecting options button 6712 may display a configure widget popup6800 (shown in FIG. 68). Configure widget popup 6800 may allow a user toedit the widget title 6802, delete the mapped point, edit the names ofthe mapped point, define the decimal places for the values of the mappedpoint, edit the minimum and maximum of the color range for heat map6706, and select a color palate for heat map 6706. In some embodiments,configure widget popup 6800 includes a preview of heat map 6706. Heatmap widget 6702 may automatically update heat map 6706 based on the timeinterval and custom filter selected. For example, selecting a timeinterval of one week may result in heat map 6706 which includes hourlyvalues for each hour in the selected week (shown in FIG. 67). However,selecting a time interval of one year may result in heat map 6902 whichincludes energy consumption values (e.g., hourly, daily, etc.) for eachday in the year.

Text Box Widget

Referring now to FIGS. 70-71, an interface 7000 for creating andconfiguring a text box widget 7002 is shown, according to an exemplaryembodiment. Text box widget 7002 can be created by selecting the createwidgets button 5904 in ad hoc dashboard 5900 and selecting text box fromthe display dropdown menu 6010. Clicking anywhere within text box widget7002 may display a menu 7004 to add or edit text. A user can change thefont, size, color, or other attributes of the text via menu 7004.Clicking outside text box widget 7002 may hide menu 7004. Text boxwidget 7002 can be moved, resized, duplicated, and deleted by selectingvarious options presented via interface 7000.

Image Widget

Referring now to FIGS. 72-73, an interface 7200 for creating andconfiguring an image widget 7202 is shown, according to an exemplaryembodiment. Image widget 7202 can be created by selecting the createwidgets button 5904 in ad hoc dashboard 5900 and selecting image fromthe display dropdown menu 6010. When image widget 7202 is first created,widget 7202 may be blank or may display text that instructs a user howto upload an image 7204 to widget 7202. Image 7204 can be selected via aconfigure widget popup 7300. Configure widget popup 7300 may allow theuser to edit the widget title 7302 and select an image via imageselector 7304. The selected image 7204 may occupy the entire area ofimage widget 7202.

Time and Date Widgets

Referring now to FIGS. 74-78, an interface 7400 for creating andconfiguring time and date widgets is shown, according to an exemplaryembodiment. Time and date widgets can include a date widget 7402 (shownin FIG. 74), a digital clock widget 7602 (shown in FIG. 76), and ananalog clock widget 7702 (shown in FIG. 77). Date widget 7402 can becreated by selecting the create widgets button 5904 in ad hoc dashboard5900 and selecting date display from the time & date dropdown menu 6008.Date widget 7402 may include graphics or text 7404 that indicates thecurrent date, day of the week, month, year, or other date information.Date widget 7402 can be edited via a configure widget popup 7500 whichallows a user to edit the widget title 7502, time zone 7504, and otherinformation associated with date widget 7402.

Digital clock widget 7602 can be created by selecting the create widgetsbutton 5904 in ad hoc dashboard 5900 and selecting digital clock fromthe time & date dropdown menu 6008. Similarly, analog clock widget 7702can be created by selecting the create widgets button 5904 in ad hocdashboard 5900 and selecting analog clock from the time & date dropdownmenu 6008. Digital clock widget 7602 may include a digital clock 7604,whereas analog clock widget 7702 may include an analog clock 7704. Clockwidgets 7602 and 7702 can be edited via a configure widget popup 7800which allows a user to edit the widget title 7802, time zone 7804, andother information associated with clock widgets 7602 and 7702.

Weather Widgets

Referring now to FIGS. 79-81, an interface 7900 for creating andconfiguring weather widgets is shown, according to an exemplaryembodiment. Weather widgets can include a current weather widget 7902(shown in FIG. 79) and a weather forecast widget 8002 (shown in FIG.80). Current weather widget 7902 can be created by selecting the createwidgets button 5904 in ad hoc dashboard 5900 and selecting currentweather from the weather dropdown menu 6012. Current weather widget 7902may include graphics or text that indicate a geographic location 7904and the current weather 7906 at the geographic location 7904.

Weather forecast widget 8002 can be created by selecting the createwidgets button 5904 in ad hoc dashboard 5900 and selecting weatherforecast from the weather dropdown menu 6012. Weather forecast widget8002 may include graphics or text that indicate a geographic location8004, the current weather 8006 at the geographic location 8004, and aforecast of future weather 8008 at the geographic location 8004. Weatherwidgets 7902 and 8002 can be edited via a configure widget popup 8100which allows a user to edit the widget title 8102, location 8104, daterange 8106, and other information associated with weather widgets 7902and 8002.

Dashboard Sharing

Referring now to FIGS. 82-83, a dashboard sharing interface 8300 isshown, according to an exemplary embodiment. Sharing interface 8300 maybe displayed in response to selecting share icon 8202 in ad hocdashboard 5900. Sharing interface 8300 can be used to share an instanceof ad hoc dashboard 5900 with other users or groups once ad hocdashboard 5900 has been created. Sharing interface 8300 is shown toinclude a users tab 8310 and a groups tab 8312. Selecting users tab 8310may display a list of users 8302 present in the system along with theirroles 8304 and email addresses 8306. Similarly, selecting groups tab8312 may display a list of groups present in the system (e.g.,administrators, building owners, service technicians, etc.). Sharinginterface 8300 may allow one or more users or groups to be selected.Clicking share button 8314 may then share ad hoc dashboard 5900 with theselected users or groups.

In some embodiments, sharing interface 8300 automatically checks whetherthe users or groups are authorized to view ad hoc dashboard 5900. Thischeck may be performed before populating the list of users 8302 andgroups or in response to a user or group being selected. For example,only authorized users may be shown in the list of users 8302 in someembodiments. In other embodiments, all users and groups may be displayedin sharing interface 8300, but a warning message may be provided if anunauthorized user or group is selected. When ad hoc dashboard 5900 isshared, another tab may be added to the interfaces provided to the userswith whom ad hoc dashboard 5900 is shared. The users can select the newtab may to view the shared instance of ad hoc dashboard 5900.

Stacked Chart Widget

Referring now to FIGS. 84-85, an interface 8400 for creating andconfiguring a stacked chart widget 8402 is shown, according to anexemplary embodiment. Stacked chart widget 8402 can be created byselecting the create widgets button 5904 in ad hoc dashboard 5900 andselecting stacked chart from the charting dropdown menu 6006. Upondragging and dropping a point into stacked chart widget 8402, a stackedchart 8404 of the timeseries data associated with the selected point maybegin populating. Any number of points can be added to stacked chartwidget 8402 as long as the points have the same unit of measure. In someembodiments, interface 8400 is configured to display a notification thatonly points with the same unit of measure are allowed if a user attemptsto add points with different units of measure.

Stacked chart 8404 is shown to include a set of columns 8412. Each ofcolumns 8412 may correspond to a particular time and may be associatedwith one or more samples that have timestamps of the corresponding time.If multiple points are added to stacked chart 8404, each of columns 8412may be divided into multiple portions. For example, each of columns 8412is shown to include a first portion 8406, a second portion 8408, and athird portion 8410. Each of portions 8406-8410 may correspond to adifferent timeseries or different point. The values of the correspondingtimeseries may be represented by the size or height of each portion8406-8410. In other embodiments, stacked chart 8404 may includehorizontal bars rather than vertical columns 8412. A key or legend 8414may indicate the names of the points associated with each portion8406-8410. In some embodiments, point names are displayed in the format“meter/equipment name—point name.”

In some embodiments, interface 8400 is configured to display a tooltipwhen a user hovers over any portion 8406-8410 of columns 8412. Thetooltip may display various attributes of meter, sample, or timeseriesassociated with the portion. For example, hovering over portion 8406 maycause the tooltip to display the timestamp associated with the column8412 in which portion 8406 is located, the name of the meter associatedwith portion 8406 (e.g., Meter1-kWh), the timeseries value associatedwith portion 8406 (e.g., 134 kWh), and the percentage of the totalcolumn 8412 which portion 8406 comprises (e.g., 13%). For example, ifthe total energy consumption of a particular column 8412 (i.e., the sumof portions 8406-8410) is 1000 kWh and portion 8406 has a value of 130kWh, the tooltip may display a percentage of 13% since 130 kWh is 13% ofthe total 1000 kWh.

Stacked chart widget 8402 can be edited via a configure widget popup8500. Configure widget popup 8500 may allow a user to edit the widgettitle 8502, edit the names of the mapped points 8504, delete the mappedpoints 8504, define decimal places for the mapped points 8504, and makeother adjustments to the configuration of stacked chart widget 8402. Insome embodiments, configure widget popup 8500 includes a preview ofstacked chart 8404. The preview of stacked chart 8404 can beautomatically updated in real time when changes are made via configurewidget popup 8500 to allow the user to view the effects of the changesbefore applying the changes to stacked chart 8404. Stacked chart widget8402 may include options to resize, maximize, duplicate, delete, move,adjust the theme, and otherwise edit stacked chart widget 8402. In someembodiments, stacked chart widget 8402 includes data aggregation options(as described with reference to FIGS. 64-66), unit conversion options,and supports weather service points.

Pie Chart Widget

Referring now to FIGS. 86-87, an interface 8600 for creating andconfiguring a pie chart widget 8602 is shown, according to an exemplaryembodiment. Pie chart widget 8602 can be created by selecting the createwidgets button 5904 in ad hoc dashboard 5900 and selecting pie chartfrom the charting dropdown menu 6006. Upon dragging and dropping a pointinto pie chart widget 8602, a pie chart 8604 of the timeseries dataassociated with the selected point may begin populating. Any number ofpoints can be added to pie chart widget 8602 as long as the points havethe same unit of measure. In some embodiments, interface 8600 isconfigured to display a notification that only points with the same unitof measure are allowed if a user attempts to add points with differentunits of measure.

If multiple points are added to pie chart 8604, pie chart 8604 may bedivided into multiple portions. For example, pie chart 8604 is shown toinclude a first portion 8606, a second portion 8608, and a third portion8610. Each of portions 8606-8610 may correspond to a differenttimeseries or different point. The values of the correspondingtimeseries may be represented by the size or arc length of each portion8606-8610. A key or legend 8614 may indicate the names of the pointsassociated with each portion 8606-8610. In some embodiments, point namesare displayed in the format “meter/equipment name—point name.”

In some embodiments, interface 8600 is configured to display a tooltipwhen a user hovers over any portion 8606-8610 of pie chart 8604. Thetooltip may display various attributes of meter, sample, or timeseriesassociated with the portion. For example, hovering over portion 8606 maycause the tooltip to display the name of the meter associated withportion 8606 (e.g., Meter1-kWh), the timeseries value associated withportion 8606 (e.g., 134 kWh), and the percentage of the total pie chart8604 which portion 8606 comprises (e.g., 13%). For example, if the totalenergy consumption represented by pie chart 8604 (i.e., the sum ofportions 8606-8610) is 1000 kWh and portion 8606 has a value of 130 kWh,the tooltip may display a percentage of 13% since 130 kWh is 13% of thetotal 1000 kWh.

Pie chart widget 8602 can be edited via a configure widget popup 8700.Configure widget popup 8700 may allow a user to edit the widget title8702, edit the names of the mapped points 8704, delete the mapped points8704, define decimal places for the mapped points 8704, and make otheradjustments to the configuration of pie chart widget 8602. In someembodiments, configure widget popup 8700 includes a preview of pie chart8604. The preview of pie chart 8604 can be automatically updated in realtime when changes are made via configure widget popup 8700 to allow theuser to view the effects of the changes before applying the changes topie chart 8604. Pie chart widget 8602 may include options to resize,maximize, duplicate, delete, move, adjust the theme, and otherwise editpie chart widget 8602.

Stuck Point Detection

Referring now to FIG. 88, a point configuration interface 8800 is shown,according to an exemplary embodiment. Interface 8800 may be a componentof data sources setup interface 4000, as described with reference toFIGS. 40-45. In some embodiments, point configuration interface 8800 isdisplayed when a user selects data sources tile 3604 in setup interface4000 and selects a data point 4304. Point configuration interface 8800allows the user to change various attributes 4302 of the data point 4304such as units, minimum value, maximum value, point name, etc.

In some embodiments, point configuration interface 8800 allows a user todefine a stuck point definition for the selected point 4304. The stuckpoint definition may be treated as a fault detection rule which can beevaluated by analytics service 524. For example, point configurationinterface 8800 is shown to include a detect stuck point checkbox 8802.When checkbox 8802 is selected, analytics service 524 may beginmonitoring the selected point 4304. Interface 8800 may also allow a userto choose a time period associated with the stuck point definition. Forexample, point configuration interface 8800 is shown to include a timeperiod box 8804 which allows the user to define a threshold amount oftime to use in the stuck point definition (e.g., one hour, two days,etc.).

Analytics service 524 may monitor the value of the selected point 4304and may determine whether the value has remained same for an amount oftime exceeding the threshold amount of time specified via time periodbox 8804. If the value of the point has not changed for an amount oftime exceeding the threshold, analytics service 524 may determine thatthe point is stuck and may generate a stuck point fault indication 8902(shown in FIG. 89). Analytics service 524 may display the stuck pointfault indication 8902 along with other fault indications in pendingfaults window 8900.

Configuration of Exemplary Embodiments

The construction and arrangement of the systems and methods as shown inthe various exemplary embodiments are illustrative only. Although only afew embodiments have been described in detail in this disclosure, manymodifications are possible (e.g., variations in sizes, dimensions,structures, shapes and proportions of the various elements, values ofparameters, mounting arrangements, use of materials, colors,orientations, etc.). For example, the position of elements can bereversed or otherwise varied and the nature or number of discreteelements or positions can be altered or varied. Accordingly, all suchmodifications are intended to be included within the scope of thepresent disclosure. The order or sequence of any process or method stepscan be varied or re-sequenced according to alternative embodiments.Other substitutions, modifications, changes, and omissions can be madein the design, operating conditions and arrangement of the exemplaryembodiments without departing from the scope of the present disclosure.

The present disclosure contemplates methods, systems and programproducts on any machine-readable media for accomplishing variousoperations. The embodiments of the present disclosure can be implementedusing existing computer processors, or by a special purpose computerprocessor for an appropriate system, incorporated for this or anotherpurpose, or by a hardwired system. Embodiments within the scope of thepresent disclosure include program products comprising machine-readablemedia for carrying or having machine-executable instructions or datastructures stored thereon. Such machine-readable media can be anyavailable media that can be accessed by a general purpose or specialpurpose computer or other machine with a processor. By way of example,such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROMor other optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to carry or storedesired program code in the form of machine-executable instructions ordata structures and which can be accessed by a general purpose orspecial purpose computer or other machine with a processor. Combinationsof the above are also included within the scope of machine-readablemedia. Machine-executable instructions include, for example,instructions and data which cause a general purpose computer, specialpurpose computer, or special purpose processing machines to perform acertain function or group of functions.

Although the figures show a specific order of method steps, the order ofthe steps may differ from what is depicted. Also two or more steps canbe performed concurrently or with partial concurrence. Such variationwill depend on the software and hardware systems chosen and on designerchoice. All such variations are within the scope of the disclosure.Likewise, software implementations could be accomplished with standardprogramming techniques with rule based logic and other logic toaccomplish the various connection steps, processing steps, comparisonsteps and decision steps.

What is claimed is:
 1. A building energy management system comprising: aplurality of pieces of building equipment of a building, wherein atleast one of the plurality of pieces of building equipment is configuredto monitor and control a variable associated with the building and oneor more of the plurality of pieces of building equipment are configuredto generate first raw data samples of a first data point associated witha first measured variable of the building and second raw data samples ofa second data point associated with a second measured variable of thebuilding; a data collector configured to: collect the first raw datasamples and the second raw data samples from the building equipment;generate a first raw data timeseries comprising a plurality of the firstraw data samples; and generate a second raw data timeseries comprising aplurality of the second raw data samples; one or more data platformservices configured to: generate a virtual data point for a non-measuredvariable of the building; and derive a virtual data timeseries for thevirtual data point from a combination of the first raw data timeseriesfor the first data point and the second raw data timeseries for thesecond data point; and a timeseries database configured to store aplurality of timeseries associated with the virtual data point, theplurality of timeseries comprising the first raw data timeseries, thesecond raw data timeseries, and the virtual data timeseries.
 2. Thebuilding energy management system of claim 1, wherein the data platformservices comprise a sample aggregator configured to: automaticallygenerate a data rollup timeseries comprising a plurality of aggregateddata samples by aggregating the first raw data samples as the first rawdata samples are collected from the building equipment; and store thedata rollup timeseries in the timeseries database.
 3. The buildingenergy management system of claim 1, wherein the data platform servicescomprise an analytics service configured to: perform one or moreanalytics using the first raw data timeseries; generate a resultstimeseries comprising a plurality of result samples indicating resultsof the analytics; and store the results timeseries in the timeseriesdatabase.
 4. The building energy management system of claim 1, whereinthe one or more data platform services are configured to derive thevirtual data timeseries from the combination of the first raw datatimeseries and the second raw data timeseries by deriving the virtualdata timeseries based on a combination of a first virtual datatimeseries and a second virtual data timeseries; wherein the one or moredata platform services configured to: generate a first virtual datapoint for a first non-measured variable of the building; determining thefirst virtual data timeseries for the first virtual data point based onthe first raw data timeseries; generating a second virtual data pointfor a second non-measured variable of the building; determining thesecond virtual data timeseries for the second virtual data point basedon the second raw data timeseries.
 5. The building energy managementsystem of claim 1, wherein the system further comprises an energymanagement application configured to generate an ad hoc dashboardcomprising a widget and to associate the widget with the virtual datapoint, wherein the widget is configured to display a graphicalvisualization of the plurality of timeseries associated with the virtualdata point and comprises at least one interactive user interface optionfor switching between the plurality of timeseries associated with thevirtual data point.
 6. The building energy management system of claim 5,wherein the ad hoc dashboard comprises a widget creation interfacecomprising a plurality of selectable widget types, each of the widgettypes corresponding to a different type of widget the ad hoc dashboardis configured to create, the widget types comprising at least one of: acharting widget; a data visualization widget; a display widget; a timeor date widget; and a weather information widget.
 7. The building energymanagement system of claim 5, wherein the widget is a charting widgetconfigured to display a chart of the plurality of timeseries associatedwith the virtual data point, the chart comprising at least one of: aline chart; an area chart; a column chart; a bar chart; a stacked chart;and a pie chart.
 8. The building energy management system of claim 5,wherein the widget is configured to: generate a heat map comprising aplurality of cells, each of the cells corresponding to a differentsample of the virtual data point associated with the widget; identify anumerical data value for each of the samples corresponding to the cellsof the heat map; and assign a color to each cell of the heat map basedon the numerical data value of the corresponding sample.
 9. The buildingenergy management system of claim 5, wherein the ad hoc dashboard isconfigured to: display a points list comprising a plurality of pointsdetected in the building energy management system; receive a user inputdragging and dropping one or more of the points from the points listonto the widget; and associate the one or more points with the widget inresponse to the user input dragging and dropping one or more of thepoints from the points list onto the widget.
 10. The building energymanagement system of claim 5, wherein: the timeseries database isconfigured to store a plurality of timeseries associated with aplurality of different data points; the ad hoc dashboard is configuredto associate the widget with each of the plurality of timeseriesassociated with the plurality of different data points; and the widgetis configured to display a graphical visualization of each of theplurality of timeseries associated with the widget.
 11. The buildingenergy management system of claim 10, wherein the widget is configuredto: determine a unit of measure for each of the plurality of timeseriesassociated with the widget; generate a line chart comprising a pluralityof lines, each of the plurality of lines corresponding to one or theplurality of timeseries associated with the widget; assign a commoncolor to each of the plurality of lines corresponding to timeseries withthe same unit of measure; and assign different colors to each of theplurality of lines corresponding to timeseries with different units ofmeasure.
 12. A method for a building energy management system, themethod comprising: operating at least one of a plurality of pieces ofbuilding equipment to monitor and control a variable in a building;collecting first raw data samples of a first data point associated witha first non-measured variable of the building and second raw datasamples of a second data point associated with a second non-measuredvariable of the building from one or more of the plurality of pieces ofbuilding equipment; generating a first raw data timeseries comprising aplurality of the first raw data samples; generating a second raw datatimeseries comprising a plurality of the second raw data samples;generating a virtual data point for a non-measured variable of thebuilding; deriving a virtual data timeseries for the virtual data pointfrom a combination of the first raw data timeseries for the first datapoint and the second raw data timeseries for the second data point; andstoring a plurality of timeseries associated with the virtual data pointin a timeseries database, the plurality of timeseries comprising thefirst raw data timeseries, the second raw data timeseries, and thevirtual data timeseries.
 13. The method of claim 12, wherein the methodfurther comprises: automatically generating a data rollup timeseriescomprising a plurality of aggregated data samples by aggregating thefirst raw data samples as the raw data samples are collected from thebuilding equipment; and storing the data rollup timeseries in thetimeseries database.
 14. The method of claim 12, further comprising:performing one or more analytics using the first raw data timeseries;generating a results timeseries comprising a plurality of result samplesindicating results of the analytics; and storing the results timeseriesin the timeseries database.
 15. The method of claim 12, furthercomprising generating an ad hoc dashboard comprising a widget associatedwith the virtual data point, wherein the widget is configured to displaya graphical visualization of the plurality of timeseries associated withthe virtual data point and comprises at least one interactive userinterface option for switching between the plurality of timeseriesassociated with the virtual data point.
 16. The method of claim 12,wherein deriving the virtual data timeseries from the combination of thefirst raw data timeseries and the second raw data timeseries comprisesderiving the virtual data timeseries based on a combination of a firstvirtual data timeseries and a second virtual data timeseries; whereinthe method further comprises: generating a first virtual data point fora first non-measured variable of the building; determining the firstvirtual data timeseries for the first virtual data point based on thefirst raw data timeseries; generating a second virtual data point for asecond non-measured variable of the building; and determining the secondvirtual data timeseries for the second virtual data point based on thesecond raw data timeseries.
 17. A building timeseries management systemcomprising: a plurality of pieces of building equipment of a building,wherein at least one of the plurality of pieces of building equipment isconfigured to monitor and control a variable associated with thebuilding and one or more of the plurality of pieces of buildingequipment are configured to generate first raw data samples of a firstdata point associated with a first measured variable of the building andsecond raw data samples of a second data point associated with a secondmeasured variable of the building; and a processing circuit configuredto: collect the first raw data samples and the second raw data samplesfrom the building equipment; generate a first raw data timeseriescomprising a plurality of the first raw data samples; generate a secondraw data timeseries comprising a plurality of the second raw datasamples; generate a virtual data point for a non-measured variable ofthe building; derive a virtual data timeseries for the virtual datapoint from a combination of the first raw data timeseries for the firstdata point and the second raw data timeseries for the second data point;and store a plurality of timeseries associated with the virtual datapoint, the plurality of timeseries comprising the first raw datatimeseries, the second raw data timeseries, and the virtual datatimeseries.
 18. The building timeseries management system of claim 17,wherein the processing circuit is configured to generate an ad hocdashboard comprising a widget and to associate the widget with thevirtual data point, wherein the widget is configured to display agraphical visualization of the plurality of timeseries associated withthe virtual data point and comprises at least one interactive userinterface option for switching between the plurality of timeseriesassociated with the virtual data point.
 19. The building timeseriesmanagement system of claim 17, wherein the processing circuit isconfigured to derive the virtual data timeseries from the combination ofthe first raw data timeseries and the second raw data timeseries byderiving the virtual data timeseries based on a combination of a firstvirtual data timeseries and a second virtual data timeseries; whereinthe processing circuit is configured to: generate a first virtual datapoint for a first non-measured variable of the building; determine thefirst virtual data timeseries for the first virtual data point based onthe first raw data timeseries; generate a second virtual data point fora second non-measured variable of the building; and determine the secondvirtual data timeseries for the second virtual data point based on thesecond raw data timeseries.
 20. The building timeseries managementsystem of claim 17, wherein the processing circuit is configured to:automatically generate a data rollup timeseries comprising a pluralityof aggregated data samples by aggregating the first raw data samples asthe first raw data samples are collected from the building equipment;and store the data rollup timeseries in the timeseries database.